Re: "Why is emacs so square?"

Re: "Why is emacs so square?"

[Jeff Norden]

Copied below is what I've posted to lwn.net in response to the article "Making
Emacs popular again" (https://lwn.net/Articles/819452/) about this thread.
Some of it, particularly the last part, is in response to that article rather
than anything that anyone has or would say on the emacs-devel list.
------------------------------
I'm late to this party, but as a longtime user of Gnu emacs, I feel obligated
to weigh in.  I've been using emacs on an almost daily basis for 30+ years.  I
use rmail for about 90% of my email.  I use a customized version of TeX mode
for composing documents, which include exams/quizzes/handout for the classes I
teach, research-related work, as well as mundane letters, memos, notes, etc.
I use emacs for all of the software that I write and/or dabble with, mostly
Perl and C.  I use shell-mode about as often as I use a terminal window
(currently mate-terminal, a fork of the pre-gnome-3 gnome-terminal).

To start with, the idea that emacs "needs" to have more users to prevent it
from becoming "extinct" is basically absurd.  Free software, by its very
nature, *can't* become extinct.  Even if current trends/fads mean that there
is a lull in the number of people using Gnu emacs today, the source code will
still be available for future generations to discover and use.  It's about
like saying that we must find a way to make the "Early New English" language
of the 17th century more appealing and widely spoken in order to prevent the
works of Shakespeare from becoming extinct.  Even if, for some reason, people
stopped reading and producing Shakespeare's plays for a number of years, they
would undoubtedly be re-discovered and become popular again.

This all seems to be part of the current insane attitude that software, and
technology in general, is some sort of perishable commodity with the shelf
life of milk.  Somehow, if it isn't updated every month or so, it just isn't
any good any more, even though it still does what it used to and your needs
for it haven't changed.

Emacs has never been an editor for "casual" user.  It doesn't compete with
notepad, any of the various "office" editors (open source or not), or even
vi/vim.  Gnu emacs is for people that want an extensible editor that gives
them complete control over how it operates, and can be easily and freely
customized to accomplish any sort of task that they want it to.  This sort of
freedom comes with a price - you need to invest some time and effort in order
to learn how to use it effectively.  But for many of us, it is an effort that
has been more than worthwhile.

In my opinion, it would be incredibly counterproductive to try to attract
people who don't need the functionality that emacs provides, or who aren't
willing to put forth the effort required to learn how to effectively use that
functionality.  I believe this means that any person who's decision on whether
or not to use an editor is swayed by the appearance of buttons or rounded
corners is someone who should *not* be encouraged to start using emacs.  If
you are not attracted to emacs by the features it provides and the tasks it
can accomplish, then please find an editor that will better suit your needs.

On the other hand, if someone wants to add such features for their own
benefit, perhaps because they feel it will enhance their own aesthetic
experience while using emacs, then by all means do so.  That is the whole
point of free software, after all.  But adding these in an attempt to attract
more users is a bad idea.

My *fear* is that a major effort to increase the "user base" will lead to the
transformation of emacs into something that doesn't serve anybody's needs very
well.  This is happening in many open source projects, where all sorts of
functionality has been deprecated and then removed because of the perception
that it isn't needed or being used by a large enough fraction of users.  The
recent loss of malloc_get_state() and malloc_set_state() are examples that are
particularly relevant to emacs.

Even in emacs, I personally found it a bit annoying to type "M-x count lines
region" only to be told in the mini-buffer that:
  ‘count-lines-region’ is obsolete; use ‘count-words-region’ instead.
But this was easily fixed by adding a single line to my .emacs file.  However,
if large blocks of code start disappearing from the source, or changes are
made that render existing elisp files unusable, then emacs really will run the
risk of becoming extinct.

For example, a package of elisp functions that I wrote 30 years ago for
emacs-18, which I use to record and average student grades, still works just
fine with emacs-26.  TeX is the only other software that I know of with this
level of stability.  It seems that there are very few people today who, like
Knuth and Stallman, take a long-term view of what they are trying to
accomplish.  I could go on along these lines, but this is probably sufficient.

----

However, I feel that I must respond directly to some of the comments about RMS
that have been made, along the lines of "emacs would be better without him" or
his "signature tantrums."  I'll respond in a way that RMS never would, because
he is far too polite:

   Do you have any idea who the f*** you are talking about!!?

When Richard founded the FSF, which basically started the free software
movement, people tried to write him off as some sort of extremest nutcase.
"Nobody will write software and just give it away" was a common criticism.
Well, history has shown that Stallman was correct, and his critics were the
nutcases.  It's quite possible that there would be almost no free software, no
linux or lwn.net, no gitlab/github, etc, etc, if it had not been for his
unfailing efforts and unwavering belief in free software though the years.  My
own opinion is that, if anything, Richard's opinions and views are a bit too
mild and conservative.

The arrogance of youth is natural.  I was certainly guilty of it when I was
young.  But there is no excuse for disrespecting the people who basically
built the universe that you currently enjoy inhabiting.

-Jeff

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 26.05.2020 20:09, Jeff Norden wrote:
> This all seems to be part of the current insane attitude that software, and
> technology in general, is some sort of perishable commodity with the shelf
> life of milk.  Somehow, if it isn't updated every month or so, it just isn't
> any good any more, even though it still does what it used to and your needs
> for it haven't changed.

By that logic, you shouldn't worry too much about what happens to its 
development either: after all, you could continue to use one of the 
versions already released for 10 or 20 or however more years.

Re: "Why is emacs so square?"

[Arthur Miller]

Jeff Norden <jnorden@math.tntech.edu> writes:

Interesting read, but there are some fallacies, or maybe not a fallacies
but implicit assumptions that maybe are not justified:


>   Free software, by its very
> nature, *can't* become extinct.  Even if current trends/fads mean that there
> is a lull in the number of people using Gnu emacs today, the source code will
> still be available for future generations to discover and use.  It's about
> like saying that we must find a way to make the "Early New English" language
> of the 17th century more appealing and widely spoken in order to prevent the
> works of Shakespeare from becoming extinct.  Even if, for some reason, people
> stopped reading and producing Shakespeare's plays for a number of years, they
> would undoubtedly be re-discovered and become popular again.
Njah, but software is not a literar work. I don't think that people are
even reading Shakespeare with same enthusiasm and appreciation as they
did back in his own time. I don't think they appreciate him less today,
but they probably appreciate him in a different way. I don't think this
analogy works for software though, since software is written to be used,
practially.

> This all seems to be part of the current insane attitude that software, and
> technology in general, is some sort of perishable commodity with the shelf
> life of milk.  Somehow, if it isn't updated every month or so, it just isn't
> any good any more, even though it still does what it used to and your needs
> for it haven't changed.
As a continuation of above, the software is not written to be just
appreciated.

If it ain't developed it will stop to work when the machine it works on
stops to exist, or the OS, or the ABIs changes etc. So to be continually
used software has to be continually updated as the system below it
updates. If we got stabile systems that will continues to work unchanged
then maybe the above would hold. I don't think though that current
hardware/OS/lib eco system is there yet. Also software is hard to write
have I heard somewhere and there will be bugs. Butgs needs to be fixed!
A bug fix means update. As we use software more and discover and fix
more bugs, updates will be needed. One can maybe stop adding features,
sure, but somehow people come with more desires and feature requests all
the time, so yet again, more updates, more bugs, more updates ... ehh. I
don't know, I don't see really analogy with literal work here. Evergreen
software has developed as an answer to certain human patterns, it ain't
come out from thin air, so I don't think it is really insane attitude as
the professor, with all the respect, writes.

> Emacs has never been an editor for "casual" user.  It doesn't compete with
> notepad, any of the various "office" editors (open source or not), or even
> vi/vim.  Gnu emacs is for people that want an extensible editor that gives
> them complete control over how it operates, and can be easily and freely
> customized to accomplish any sort of task that they want it to.
Sure, but what says that one does have to exclude the other?

> This sort of
> freedom comes with a price - you need to invest some time and effort in order
> to learn how to use it effectively.  But for many of us, it is an effort that
> has been more than worthwhile.
Why? What says price is mandated? Why can't easy things be easy,
no-effort, and complicated things left for people who wish to dive in? I
feel there is some prejudice and assumption there simply based on how
computer usage looks today. But what says things have to be as they are?
Can't we change the world? :-)

> In my opinion, it would be incredibly counterproductive to try to attract
> people who don't need the functionality that emacs provides, or who aren't
> willing to put forth the effort required to learn how to effectively use that
> functionality.  I believe this means that any person who's decision on whether
> or not to use an editor is swayed by the appearance of buttons or rounded
> corners is someone who should *not* be encouraged to start using emacs.  If
> you are not attracted to emacs by the features it provides and the tasks it
> can accomplish, then please find an editor that will better suit your needs.
I think rounded buttons were more of a joke, but anyway, I don't
understand why it would be counterproductive to attract people who are
not willing to become finger octopusses just to use Emacs? More people
means more eyes, more usage scenarios, more bugs descovered, more users
becomming with time power users, more functionality added, better
software in the long term and maybe more momentum to free world. I don't
understand how someone can see bigger grass roots as a diminutive. 

> Even in emacs, I personally found it a bit annoying to type "M-x count lines
> region" only to be told in the mini-buffer that:
>   ‘count-lines-region’ is obsolete; use ‘count-words-region’ instead.
> But this was easily fixed by adding a single line to my .emacs file.
Poor you, I really feel your pain.

> However,
> if large blocks of code start disappearing from the source, or changes are
> made that render existing elisp files unusable, then emacs really will run the
> risk of becoming extinct.
Why would large blocks of code disappear? Nobody said Emacs should go
rewritten from scratch, stuff should get thrown away etc.

> For example, a package of elisp functions that I wrote 30 years ago for
> emacs-18, which I use to record and average student grades, still works just
> fine with emacs-26.  TeX is the only other software that I know of with this
> level of stability.  It seems that there are very few people today who, like
> Knuth and Stallman, take a long-term view of what they are trying to
> accomplish.  I could go on along these lines, but this is probably sufficient.
I don't know, I think we have never before had so many textbooks on how
to design and write software, especially libraries and APIs so they are
easy to change and modify withouth affecting existing adopters? Isn't
entire OOP an answer to that? Are you really sure there are so few
people today who takes long term stability that lightly? 

> ----
>
> However, I feel that I must respond directly to some of the comments about RMS
> that have been made, along the lines of "emacs would be better without him" or
> his "signature tantrums."  I'll respond in a way that RMS never would, because
> he is far too polite:
>
>    Do you have any idea who the f*** you are talking about!!?
>
> When Richard founded the FSF, which basically started the free software
> movement, people tried to write him off as some sort of extremest nutcase.
> "Nobody will write software and just give it away" was a common criticism.
> Well, history has shown that Stallman was correct, and his critics were the
> nutcases.  It's quite possible that there would be almost no free software, no
> linux or lwn.net, no gitlab/github, etc, etc, if it had not been for his
> unfailing efforts and unwavering belief in free software though the years.  My
> own opinion is that, if anything, Richard's opinions and views are a bit too
> mild and conservative.
>
> The arrogance of youth is natural.  I was certainly guilty of it when I was
> young.  But there is no excuse for disrespecting the people who basically
> built the universe that you currently enjoy inhabiting.
>
> -Jeff
I completely agree here. I don't know though if it is relevant, since
making Emacs more of a in-time player in 21st century is by no mean a
dissrespect to RMS or anyone else.

Re: "Why is emacs so square?"

[Jeff Norden]

This is a follow-up to may post from May, plus a concrete suggestion.

Of course, my Shakespere analogy was a bit tongue-in-cheek.  But software
and literature are both artistic human activities, and have more
similarities than you might think.  This would be more apparent if Knuth's
concept of Literate Programming were used more widely.

Of course, software *must* be updated regularly.  But I still contend that
the current pace borders on insanity.  Updates often seem to be done merely
to satisfy some current "ui" or "ux" trends.  In other projects, including
GPL ones, this has resulted in removing functionality and stripping out
large swaths of source code.  I would hate to see that happen to emacs.
There is a Doonsbury cartoon that I like, even though it refers to the most
un-free software platform in existence:
  https://www.gocomics.com/doonesbury/2014/03/16

I think the risk of emacs becoming extinct because of a lack of users is
overblown.  But, I probably overstepped in arguing for some sort of elitist
attitude.  I still think it would be counterproductive to concentrate on
superficial changes, like button shapes, just to attract more "warm
bodies."  On the other hand, anything that makes it easier for a person to
reach the point where they say:

   Hey, I never realized that you could do *that* with an editor!

is absolutely worth pursuing.  This would, hopefully, help convince them of
the value of not just emacs, but free software more generally.

----------
In this last regard, it occurs to me that a small defun from my personal
dot-emacs might help.  Everyone starting out with emacs eventually finds
themselves in some sort of state that they need to get out of.  Often a
recursive edit, sometimes several level deep.  I've never been a big fan of
ESC ESC ESC. For a while, I got in the habit of typing "M-X top-level" a
lot.  Then I added the following to my dot-emacs, and have been quite happy
with it:

    (defun keyboard-quit-strong ()
      "Run `keyboard-quit' to return emacs to a more responsive state.
    If repeated twice in a row, run `top-level' instead, to also exit
    any recursive editing levels."
      (interactive)
      (when (eq last-command 'keyboard-quit-strong)
	(setq this-command 'top-level) ;dis-arm a 3rd C-g
	(ding)
	(top-level))
      ;; Not reached after `top-level'. (A rare behavior in lisp.)
      (keyboard-quit))

    (global-set-key "\C-g" 'keyboard-quit-strong)

Here are my reasons for preferring this over ESC ESC ESC:

1) Everyone using emacs has to learn C-g, since it is the only way to
interrupt the interpreter.  One less thing to remember is always good.

2) If you manage to get yourself 10-levels deep in recursive edits somehow,
ESC ESC ESC ESC... is pretty tedious, since it only exits one level for each
three ESC's.

3) When the first ESC ESC ESC doesn't work for some reason, and you try more,
it's easy to lose count and wind up with an extra ESC.  You might type another
key before 'ESC-' appears in the echo area, with some unintended (albeit
usually benign) consequence.

4) Some of the ESC ESC ESC actions, especially delete-other-windows, seem
unexpected to me.  Isn't it more confusing, rather than helpful, to have the
window configuration you've carefully set up suddenly disappear?  I suppose it
might make sense after *Help* pops up, unless you've moved the point into the
*Help* buffer.  It seems to me that 'C-x 1' and 'C-x 2' are bindings that just
about everyone learns early on anyway, but I could be wrong.

A few other points:

If you repeatedly type C-g, the echo area toggles between "Quit" and
"Back to top level."  This nicely indicates what is going on.

If emacs is stuck in the interpreter, it takes at least three C-g's, to get
top-level to run.  Despite this, I have yet to break the 'G' key on any of my
keyboards, no matter how frustrated I've gotten :-).

I don't think I have ever accidentally exited from a recursive edit that I
wanted to keep using, such as a backtrace, by unintentionally typing C-g too
many times.  But this it is something to be considered.  On the other hand,
I've recently used this binding *a lot* along with debug-on-entry.

----------
Hope this helps, and that anyone reading this is healthy and staying safe.

-Jeff Norden

Re: "Why is emacs so square?"

[Jeff Norden]

Oops, that first line should read "...my post from May,"
Also, it looks like the list-archive software didn't pick this up as
continuing that thread, so here is a link:
  https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg03191.html

-Jeff

longtime user of emacs (was: "Why is emacs so square?")

[andres.ramirez]

Hi. Jeff.
>>>>> "Jeff" == Jeff Norden <jnorden@math.tntech.edu> writes:

    Jeff> Oops, that first line should read "...my post from May," Also, it looks like the
    Jeff> list-archive software didn't pick this up as continuing that thread, so here is a link:
    Jeff> https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg03191.html

Thanks for pointing to the link. I have lost the idea about what You were
talking about. I started with emacs22. But I have run recently emacs20.

This is just a curious question.
How many years an  emacs user needs for being considered a longtime
emacs user?.

Other questions.
Do You think vanilla emacs has good defaults?
If your answer to the previous question is "No". What would You change on
vanilla emacs defaults?

BTW. I agree with this:
--8<---------------cut here---------------start------------->8---
There is no excuse for disrespecting  people.
--8<---------------cut here---------------end--------------->8---

I use rmail for reading mbox files. gnus when reading debbugs (bug
reports). wanderlust for reading email and message-mode for composing
this email.

Best Regards

Re: longtime user of emacs

[Po Lu]

andres.ramirez <rrandresf@gmail.com> writes:

> This is just a curious question.  How many years an emacs user needs
> for being considered a longtime emacs user?.

I don't think there ever was a standard for this, so we shouldn't really
compare people based on how 'long' they have used Emacs for.

> Other questions.  Do You think vanilla emacs has good defaults?  If
> your answer to the previous question is "No". What would You change on
> vanilla emacs defaults?

I think the Emacs defaults are reasonable.  They might not be good, but
they have stood the test of time for nearly 4 (!) decades, and it
probably isn't a very good idea to change them.

There have been various platforms over the past 4 decades, most with
very different user interface 'standards' and trends.  Emacs in one form
or the other has run on all of them, and has run in a consistent way.
I don't believe it's a very good idea to change that.

Also, here's some anecdotal experience:
Modern software changing every once in a while to fullfill trends is one
of the reasons many users use Emacs.  If Emacs starts changing to
fullfill the latest UI trends, I'm reasonably sure many people would leave.

Re: longtime user of emacs (was: "Why is emacs so square?")

[Jeff Norden]

> Do You think vanilla emacs has good defaults?  If your answer to the
> previous question is "No". What would You change on vanilla emacs
> defaults?

I agree with Po Lu that the defaults are reasonable and should certainly
not be changed lightly.  I'll go further and say that, since emacs is
designed at its core to be customizable and extensible, the "vanilla
defaults" are far less critical than they would otherwise be.  Everyone
has their own preferences.  But it's easy to change any that differ from
the defaults.  If I'm using a "vanilla" emacs, I usually change scroll-step
(or -conservatively), but this just takes a moment.  And, if I can't
recall the variable name, I just do M-x set-variable scroll- [TAB], and
there they are.

So, I probably wouldn't argue for having the keyboard-quit-strong that I
posted above become a replacement for keyboard-quit.  Instead, if folks
think it is a worthwhile idea, maybe a customizable variable could
control the default behavior of C-g.  Then it just becomes the
relatively minor question of what the default value should be for this
variable.

-Jeff

Re: longtime user of emacs (was: "Why is emacs so square?")

[Ihor Radchenko]

> I agree with Po Lu that the defaults are reasonable and should certainly
> not be changed lightly.  I'll go further and say that, since emacs is
> designed at its core to be customizable and extensible, the "vanilla
> defaults" are far less critical than they would otherwise be.  Everyone
> has their own preferences.  But it's easy to change any that differ from
> the defaults.  If I'm using a "vanilla" emacs, I usually change scroll-step
> (or -conservatively), but this just takes a moment.  And, if I can't
> recall the variable name, I just do M-x set-variable scroll- [TAB], and
> there they are.

While I agree that the existing Emacs defaults are reasonable in
general, I do not think that they are good for users coming from an
arbitrary background.

Emacs is a very versatile tool and can be used for programming, creative
writing, research, note-taking, todo management, and many more different
fields. I do not think that a single set of defaults can satisfy users
aiming for every single use-case. Moreover, changes required to tweak
Emacs towards a specific use-case are often much more than "just takes a
moment". No surprise that we have a whole spectrum of Emacs startup kits,
which offer predefined set of tweaks for different styles of using
Emacs.

I do think that the existing Emacs defaults are a good starting point
for a new user with unknown workflows. They are generic enough to tweak
Emacs in any possible direction. However, I believe that it would be a
good option to have several sets of defaults, which would better fit
some common use-cases, like programming, note-taking, tramp, git, etc.
Then, the existing defaults will represent "Generic" use-case, but a new
user (who may or may not have programming background) might easily
select other set of defaults, which is more suitable for the user's
background and expected use-cases.

Best,
Ihor

Jeff Norden <jnorden@tntech.edu> writes:

>> Do You think vanilla emacs has good defaults?  If your answer to the
>> previous question is "No". What would You change on vanilla emacs
>> defaults?
>
> I agree with Po Lu that the defaults are reasonable and should certainly
> not be changed lightly.  I'll go further and say that, since emacs is
> designed at its core to be customizable and extensible, the "vanilla
> defaults" are far less critical than they would otherwise be.  Everyone
> has their own preferences.  But it's easy to change any that differ from
> the defaults.  If I'm using a "vanilla" emacs, I usually change scroll-step
> (or -conservatively), but this just takes a moment.  And, if I can't
> recall the variable name, I just do M-x set-variable scroll- [TAB], and
> there they are.
>
> So, I probably wouldn't argue for having the keyboard-quit-strong that I
> posted above become a replacement for keyboard-quit.  Instead, if folks
> think it is a worthwhile idea, maybe a customizable variable could
> control the default behavior of C-g.  Then it just becomes the
> relatively minor question of what the default value should be for this
> variable.
>
> -Jeff
>

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg

Re: longtime user of emacs

[Po Lu]

Ihor Radchenko <yantar92@gmail.com> writes:

> I do think that the existing Emacs defaults are a good starting point
> for a new user with unknown workflows. They are generic enough to tweak
> Emacs in any possible direction. However, I believe that it would be a
> good option to have several sets of defaults, which would better fit
> some common use-cases, like programming, note-taking, tramp, git, etc.
> Then, the existing defaults will represent "Generic" use-case, but a new
> user (who may or may not have programming background) might easily
> select other set of defaults, which is more suitable for the user's
> background and expected use-cases.

I think this solution was proposed by a few people a few months back,
when this discussion started.  It would be nice if people came up with
an idea as to how exactly this functionality is to be implemented, and a
set of better usecases than just 'programming' or 'note-taking' or
'TRAMP' or 'git'.

P.S: Please don't suggest things like `use-git-mode' or
`use-tramp-mode'. That kind of thinking doesn't work out.

Re: longtime user of emacs

[Ihor Radchenko]

> I think this solution was proposed by a few people a few months back,
> when this discussion started.  

Could you point me to relevant thread? I lost track of that discussion
at some point.

> It would be nice if people came up with
> an idea as to how exactly this functionality is to be implemented, 
> and a
> set of better usecases than just 'programming' or 'note-taking' or
> 'TRAMP' or 'git'.

As one possibility, we can try to extend "A guided tour to Emacs" and
make it more interactive.

Some thoughts:
1. The link to the tour in the welcome page is not easy to spot for a
new user. There is too much information. I might be better to show it by
default on first startup after installation.
2. Currently, the tour is one long web-page, which is not very easy to
read. I imagine that a presentation-like style (with prev/next buttons
on each page) showing one concept at a time would be easier to read.
3. The tour may as well include interactive customisation. For example,
'Migrating to Emacs' part of the tour may as well contain a clickable
element to turn on CUA mode by default.
4. The tour might ask user questions if the user is going to work with
source code, email, web-browsing, shell, etc. If the user is not
planning to work with certain things, they may as well be hidden from
menu and customisation pages. By hidden I don't mean completely hidden,
but rather "folded" - the user should be able to show them back.
For a newcomer, Emacs offers very too many different options. I believe
that it makes more sense to restrict the customisation and menus to what
user explicitly plans to do. It should be already more than enough to
start learning.
5. Similar guided tours may be created for most popular Emacs features:
   - working with source code
   - org-mode
   - version-control and collaboration
   - remote file access
   - mail
   Those tours might also offer some initial customisation, so that the
   user may disable/enable some features which are not relevant to
   his/her workflow.
   The guides should be easily accessible from menu.
6. Some new users might be confused by default file open dialogie
involving mode-line. I believe that similarly to CUA-mode, Emacs can
emulate more standard approach by offering dired as a way to open files
(not enabled by default, but offered as a customisation together with
CUA-mode).

Best,
Ihor

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> I do think that the existing Emacs defaults are a good starting point
>> for a new user with unknown workflows. They are generic enough to tweak
>> Emacs in any possible direction. However, I believe that it would be a
>> good option to have several sets of defaults, which would better fit
>> some common use-cases, like programming, note-taking, tramp, git, etc.
>> Then, the existing defaults will represent "Generic" use-case, but a new
>> user (who may or may not have programming background) might easily
>> select other set of defaults, which is more suitable for the user's
>> background and expected use-cases.
>
> I think this solution was proposed by a few people a few months back,
> when this discussion started.  It would be nice if people came up with
> an idea as to how exactly this functionality is to be implemented, and a
> set of better usecases than just 'programming' or 'note-taking' or
> 'TRAMP' or 'git'.
>
> P.S: Please don't suggest things like `use-git-mode' or
> `use-tramp-mode'. That kind of thinking doesn't work out.

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China
Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg

Re: longtime user of emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Wed, 15 Jul 2020 15:10:34 +0800
> Cc: "andres.ramirez" <rrandresf@gmail.com>, Jeff Norden <jnorden@tntech.edu>,
>  emacs-devel@gnu.org
> 
> Some thoughts:
> 1. The link to the tour in the welcome page is not easy to spot for a
> new user. There is too much information. I might be better to show it by
> default on first startup after installation.
> 2. Currently, the tour is one long web-page, which is not very easy to
> read. I imagine that a presentation-like style (with prev/next buttons
> on each page) showing one concept at a time would be easier to read.
> 3. The tour may as well include interactive customisation. For example,
> 'Migrating to Emacs' part of the tour may as well contain a clickable
> element to turn on CUA mode by default.
> 4. The tour might ask user questions if the user is going to work with
> source code, email, web-browsing, shell, etc. If the user is not
> planning to work with certain things, they may as well be hidden from
> menu and customisation pages. By hidden I don't mean completely hidden,
> but rather "folded" - the user should be able to show them back.
> For a newcomer, Emacs offers very too many different options. I believe
> that it makes more sense to restrict the customisation and menus to what
> user explicitly plans to do. It should be already more than enough to
> start learning.
> 5. Similar guided tours may be created for most popular Emacs features:
>    - working with source code
>    - org-mode
>    - version-control and collaboration
>    - remote file access
>    - mail
>    Those tours might also offer some initial customisation, so that the
>    user may disable/enable some features which are not relevant to
>    his/her workflow.
>    The guides should be easily accessible from menu.
> 6. Some new users might be confused by default file open dialogie
> involving mode-line. I believe that similarly to CUA-mode, Emacs can
> emulate more standard approach by offering dired as a way to open files
> (not enabled by default, but offered as a customisation together with
> CUA-mode).

Thank you for writing this.  I would encourage interested people to
work on some of these ideas.

Re: longtime user of emacs (was: "Why is emacs so square?")

[andrés ramírez]

Hi. Jeff.

>>>>> "Jeff" == Jeff Norden <jnorden@tntech.edu> writes:


[...]

    Jeff> If I'm using a "vanilla" emacs, I usually change scroll-step
    Jeff> (or -conservatively), but this just takes a moment.  And, if I can't recall the variable
    Jeff> name, I just do M-x set-variable scroll- [TAB], and there they are.

I tend to use vanilla emacs once per month (not regularly). One of the
things I would change would be:
--8<---------------cut here---------------start------------->8---
(defalias 'yes-or-no-p 'y-or-n-p)
--8<---------------cut here---------------end--------------->8---

The idea, is not changing it. For me It is just mentioning some things ouf of
our experience as emacs users who from time to time experience|use
vanilla-emacs. Perhaps another person who use vanilla-emacs would say
'+1' to one of our suggestions (who knows).


Best Regards

RE: "Why is emacs so square?"

[Drew Adams]

> > Eli, does this name length matter any more?
> 
> No.  Especially since we stopped splitting our manuals into foo-N
> parts long ago.
> 
> The only issue today is that renaming the Info file will make the
> successful update of the system-wide DIR file by install-info at "make
> install" time more important, otherwise people might have an old
> manual presented to them.  Not sure what this means for the various
> binary distros.  Also, we need to rework all the references we have to
> that manual in Lisp files (I found only one such reference, FWIW).

Maybe another, minor, consideration: There are
likely many references to parts of the manual
out there, beyond Emacs (e.g. on web sites).

In some cases a reference might be just textual,
e.g., "(eintr) Yanking".

In other cases it might be a URL to the manual
on line, e.g.:

https://www.gnu.org/software/emacs/manual/html_node/eintr/Yanking.html

(URLs can be redirected, of course.)

Re: "Why is emacs so square?"

[ndame]

> Maybe some improvements to the welcome screen. A better tutorial (which showcases advanced features, not just the "alien" part of Emacs) and/or some guides.

If the cursor keys work out of the box then the tutorial should
begin with features which can be used without learning new cursor keys,
demonstrating something which emacs does well or better than other
tools. Is there such a thing? Or does learning emacs mostly pay off
for the advanced user? I can't think of a feature right know where
emacs shines for the casual user.

C-v and stuff are advanced topics IMO which pay off mostly in the long
run, not at the beginning, they could be shown in an advanced section
of the tutorial later.

And for keybindings there is no real need to switch to emacs, because,
for example, vscode can also have emacs keys:

https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx


So some feature should be found which can be shown for the casual user at the beginning
of the tutorial which may convince the user that emacs is worth the effort.

IMO  starting with C-v, etc. keys just puts off must users who casually try emacs.

Re: "Why is emacs so square?"

[조성빈]

2020. 4. 25. 오전 1:39, ndame <ndame@protonmail.com> 작성:

>> Maybe some improvements to the welcome screen. A better tutorial (which showcases advanced features, not just the "alien" part of Emacs) and/or some guides.
> 
> If the cursor keys work out of the box then the tutorial should
> begin with features which can be used without learning new cursor keys,
> demonstrating something which emacs does well or better than other
> tools.

Yeah, Emacs should not position it as an obscure editor that only gurus use. 

> Is there such a thing? Or does learning emacs mostly pay off
> for the advanced user? I can't think of a feature right know where
> emacs shines for the casual user.

Org mode, magit, helm comes to my mind.
Programmability should also be mentioned — one should show a step-by-step tutorial that adds a new interactive function invokable by a keybinding.

> C-v and stuff are advanced topics IMO which pay off mostly in the long
> run, not at the beginning, they could be shown in an advanced section
> of the tutorial later.
> 
> And for keybindings there is no real need to switch to emacs, because,
> for example, vscode can also have emacs keys:
> 
> https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx
> 
> 
> So some feature should be found which can be shown for the casual user at the beginning
> of the tutorial which may convince the user that emacs is worth the effort.
> 
> IMO  starting with C-v, etc. keys just puts off must users who casually try emacs.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 20:57, 조성빈 wrote:
> Programmability should also be mentioned

As well as, specifically, that you can easily change Emacs's looks and 
behavior at runtime by evaluating code in *scratch*. Which allows for 
quick iterative development.

I know of no other mainstream editors that support this.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> Date: Sat, 25 Apr 2020 02:57:17 +0900
> 
> 2020. 4. 25. 오전 1:39, ndame <ndame@protonmail.com> 작성:
> 
> >> Maybe some improvements to the welcome screen. A better tutorial (which showcases advanced features, not just the "alien" part of Emacs) and/or some guides.
> > 
> > If the cursor keys work out of the box then the tutorial should
> > begin with features which can be used without learning new cursor keys,
> > demonstrating something which emacs does well or better than other
> > tools.
> 
> Yeah, Emacs should not position it as an obscure editor that only gurus use. 
> 
> > Is there such a thing? Or does learning emacs mostly pay off
> > for the advanced user? I can't think of a feature right know where
> > emacs shines for the casual user.
> 
> Org mode, magit, helm comes to my mind.
> Programmability should also be mentioned — one should show a step-by-step tutorial that adds a new interactive function invokable by a keybinding.

A tutorial is not for "selling" Emacs.  It's a good idea to write such
a "sales" document, but it would be a separate document.

A tutorial is supposed to teach the users how to use Emacs, so it
should indeed start from the basics.  Whether those basics should or
shouldn't begin with cursor motion is a matter of opinion, but it
would be strange to see an Emacs tutorial that would begin by showing
how to enter and use Org, Magit, Helm, and other similar packages.  I
challenge you to even write about these features without mentioning
"buffer", "window", "mode line", and other basics of the Emacs UI.
How can you talk about these without first saying something about what
they are, what they show, how they can be used, etc.?

RE: "Why is emacs so square?"

[Drew Adams]

> A tutorial is not for "selling" Emacs.  It's a good
> idea to write such a "sales" document, but it would
> be a separate document.

+1

Re: "Why is emacs so square?"

[chad]

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

Several years ago, someone put together "A guided tour of Emacs":

  https://www.gnu.org/software/emacs/tour/

I suspect what is being discussed here is a new version of that document,
possibly included directly in the build and/or linked from the default
startup screen.

~Chad

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

Re: "Why is emacs so square?"

[ndame]

> Several years ago, someone put together "A guided tour of Emacs":
>
>   https://www.gnu.org/software/emacs/tour/
>
> I suspect what is being discussed here is a new version of that document, possibly included directly in the build and/or linked from the default startup screen.
>

Pretty nice and well put together. It really should be linked from
the startup screen.

For the record, here's a page with similar purpose for vscode.
It's useful to see what the competition offers. Just scroll
down and read the titles:

https://vscodecandothat.com/

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 24 Apr 2020 18:53:56 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>,
>  조성빈 <pcr910303@icloud.com>,
>  EMACS development team <emacs-devel@gnu.org>
> 
> Pretty nice and well put together. It really should be linked from
> the startup screen.

It's already there.

Re: "Why is emacs so square?"

[chad]

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

On Fri, Apr 24, 2020 at 12:25 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Fri, 24 Apr 2020 18:53:56 +0000
> > From: ndame <ndame@protonmail.com>
> > Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>,
> >  조성빈 <pcr910303@icloud.com>,
> >  EMACS development team <emacs-devel@gnu.org>
> >
> > Pretty nice and well put together. It really should be linked from
> > the startup screen.
>
> It's already there.
>

I checked again with emacs -q on a fresh build from this morning. The
default starting text is below, but it doesn't seem to include it. I also
checked the default Help menu, where I thought that it had once been
included, but didn't find it there, either. Maybe I got removed at some
point?

Welcome to GNU Emacs, one component of the GNU/Linux operating system.
> To follow a link, click Mouse-1 on it, or move to it and type RET.
> To quit a partially entered command, type Control-g.
>


Important Help menu items:
> Emacs Tutorial Learn basic Emacs keystroke commands
> Read the Emacs Manual View the Emacs manual using Info
> (Non)Warranty GNU Emacs comes with ABSOLUTELY NO WARRANTY
> Copying Conditions Conditions for redistributing and changing Emacs
> More Manuals / Ordering Manuals  How to order printed manuals from the FSF
>


Useful tasks:
> Visit New File Specify a new file’s name, to edit the file
> Open Home Directory Open your home directory, to operate on its files
> Customize Startup Change initialization settings including this screen
>


GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo
> version 1.16.0)
>  of 2020-04-24
> Copyright (C) 2020 Free Software Foundation, Inc.
>

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Fri, 24 Apr 2020 15:52:04 -0700
> Cc: ndame <ndame@protonmail.com>, Drew Adams <drew.adams@oracle.com>, 
> 	조성빈 <pcr910303@icloud.com>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
>  > Pretty nice and well put together. It really should be linked from
>  > the startup screen.
> 
>  It's already there.
> 
> I checked again with emacs -q on a fresh build from this morning. The default starting text is below, but it
> doesn't seem to include it. I also checked the default Help menu, where I thought that it had once been
> included, but didn't find it there, either. Maybe I got removed at some point?

No, it was not removed.  It's still there, both in Emacs 27 and on
master.  But we have several different variants of the startup screen,
and what gets actually displayed depends on how you invoke Emacs and
on Emacs's capabilities in the session you started.  So how did you
start Emacs (from the shell prompt, from some icon, from some
service), and what kind of features do you have in that build?

Alternatively, just read the code in startup.el and try to figure out
why you don't have that displayed in your case.  It usually means you
lack some capability, but of course there could be some bug as well.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 21:42, chad wrote:
> Several years ago, someone put together "A guided tour of Emacs":
> 
> https://www.gnu.org/software/emacs/tour/
> 
> I suspect what is being discussed here is a new version of that 
> document, possibly included directly in the build and/or linked from the 
> default startup screen.

Thanks for the link! Probably, yes.

A heavily updated and reorganized new version.

Re: "Why is emacs so square?"

[ndame]

> Several years ago, someone put together "A guided tour of Emacs":
>
>   https://www.gnu.org/software/emacs/tour/
>

Also, it's much more pleasant looking than the built-in tutorial
which is plain text. I wonder why the tutorial looks so barebones.
Why doesn't it use colors, fonts, formatting?

There should be some tutorial-presentation-mode which is turned on
in the tutorial buffer by default and spices up it a bit by adding
text properties.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 24 Apr 2020 19:22:39 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>, 조성빈 <pcr910303@icloud.com>, EMACS development team <emacs-devel@gnu.org>
> 
> Also, it's much more pleasant looking than the built-in tutorial
> which is plain text. I wonder why the tutorial looks so barebones.
> Why doesn't it use colors, fonts, formatting?
> 
> There should be some tutorial-presentation-mode which is turned on
> in the tutorial buffer by default and spices up it a bit by adding
> text properties.

We have enriched-mode, if someone wants to add colors to the tutorial.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 21:10, Eli Zaretskii wrote:
> A tutorial is not for "selling" Emacs.

We should probably call it the "movement tutorial", or something like 
that. And make it come later in the introduction.

> how to enter and use Org, Magit, Helm, and other similar packages.  I
> challenge you to even write about these features without mentioning
> "buffer", "window", "mode line", and other basics of the Emacs UI.

All of these can be introduced much quicker than a 12-page document. And 
the user doesn't need to know *how* to do stuff before they can learn 
about the things Emacs can do.

And at least for Magit and Helm, it's perfectly possible to describe 
their selling points without first introducing what "buffers" and "mode 
line" are. Maybe even windows.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, ndame@protonmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 24 Apr 2020 21:40:55 +0300
> 
> > how to enter and use Org, Magit, Helm, and other similar packages.  I
> > challenge you to even write about these features without mentioning
> > "buffer", "window", "mode line", and other basics of the Emacs UI.
> 
> All of these can be introduced much quicker than a 12-page document.

Maybe it can, maybe it can't.  I encourage you (or someone else) to
show such a variant of the introductory text, then we'd have something
to talk about, including comparing it with what we have now.

> And at least for Magit and Helm, it's perfectly possible to describe 
> their selling points without first introducing what "buffers" and "mode 
> line" are. Maybe even windows.

Once again, "selling" is a different document.  Describing how to use
these feature without the basics could work for those who already know
the basics, but not for those who don't.  Maybe you assume that people
who read the tutorial already know the basics.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 22:22, Eli Zaretskii wrote:

>> All of these can be introduced much quicker than a 12-page document.
> 
> Maybe it can, maybe it can't.  I encourage you (or someone else) to
> show such a variant of the introductory text, then we'd have something
> to talk about, including comparing it with what we have now.

Guess it's going on my list. But if anyone starts working on the new 
version, I have a few suggestions, please hit me up.

>> And at least for Magit and Helm, it's perfectly possible to describe
>> their selling points without first introducing what "buffers" and "mode
>> line" are. Maybe even windows.
> 
> Once again, "selling" is a different document.  Describing how to use
> these feature without the basics could work for those who already know
> the basics, but not for those who don't.  Maybe you assume that people
> who read the tutorial already know the basics.

"Selling" happens first. Then the new user has more motivation to 
actually learn stuff in detail.

Re: "Why is emacs so square?"

[ndame]

>
> > Is there such a thing? Or does learning emacs mostly pay off
> > for the advanced user? I can't think of a feature right know where
> > emacs shines for the casual user.
>
> Org mode, magit, helm comes to my mind.


Orgmode is included, but helm and magit are in melpa. Emacs should feature
packages which are accessible for the new user without tinkering. Though,
if the newbie.el which can setup a beginner friendly environment if emacs
is started without config is allowed to add melpa to the package list and
install helm/magit automatically then it's ok, because then it is instantly
available  for the new user.

BTW, helm. Maybe the veterans don't recognize it, but the default emacs completion
is extremely clunky, especially if one comes from other modern tools.

A user accustomed to modern tools expects something like this:

https://resources.jetbrains.com/help/img/idea/2020.1/find_action_dialog.png

A vertical list which is instantly filtered as you type.

Compared to this the default completion is hoplessly old fashioned with its
multicolumn text display and having to press for TAB for the results.

Icomplete is a step in the right direction. The above mentioned newbie.el
should set it up instead of the default completion.

Though, it's a single line displaying completions, a vertical display
could be better, especially if the entries are longer.

And someone did it already:

https://github.com/oantolin/icomplete-vertical

Icomplete-vertical should be adopted into the core as an option and this
is how completion should be set up for newbies.

It's still not as good looking as the one on my first link, but it's
almost there. It's vertical, it gives you instant results, so it's much
closer to completion provided by modern tools (Idea, VsCode, etc.) than
the default one.

Re: "Why is emacs so square?"

[Yuan Fu]

> On Apr 25, 2020, at 12:28 PM, ndame <ndame@protonmail.com> wrote:
> 
>> 
>>> Is there such a thing? Or does learning emacs mostly pay off
>>> for the advanced user? I can't think of a feature right know where
>>> emacs shines for the casual user.
>> 
>> Org mode, magit, helm comes to my mind.
> 
> 
> Orgmode is included, but helm and magit are in melpa. Emacs should feature
> packages which are accessible for the new user without tinkering. Though,
> if the newbie.el which can setup a beginner friendly environment if emacs
> is started without config is allowed to add melpa to the package list and
> install helm/magit automatically then it's ok, because then it is instantly
> available  for the new user.
> 
> BTW, helm. Maybe the veterans don't recognize it, but the default emacs completion
> is extremely clunky, especially if one comes from other modern tools.
> 
> A user accustomed to modern tools expects something like this:
> 
> https://resources.jetbrains.com/help/img/idea/2020.1/find_action_dialog.png
> 
> A vertical list which is instantly filtered as you type.
> 
> Compared to this the default completion is hoplessly old fashioned with its
> multicolumn text display and having to press for TAB for the results.
> 
> Icomplete is a step in the right direction. The above mentioned newbie.el
> should set it up instead of the default completion.
> 
> Though, it's a single line displaying completions, a vertical display
> could be better, especially if the entries are longer.
> 
> And someone did it already:
> 
> https://github.com/oantolin/icomplete-vertical
> 
> Icomplete-vertical should be adopted into the core as an option and this
> is how completion should be set up for newbies.
> 
> It's still not as good looking as the one on my first link, but it's
> almost there. It's vertical, it gives you instant results, so it's much
> closer to completion provided by modern tools (Idea, VsCode, etc.) than
> the default one.
> 


Thanks for sharing! I tried to use icomplete with “\n” separator, but encountered the problem that this package aims to solve. This should definitely be included as bugfix.

Yuan

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 25.04.2020 23:45, Yuan Fu wrote:

>> Though, it's a single line displaying completions, a vertical display
>> could be better, especially if the entries are longer.
>>
>> And someone did it already:
>>
>> https://github.com/oantolin/icomplete-vertical
>>
>> Icomplete-vertical should be adopted into the core as an option and this
>> is how completion should be set up for newbies.
>>
>> It's still not as good looking as the one on my first link, but it's
>> almost there. It's vertical, it gives you instant results, so it's much
>> closer to completion provided by modern tools (Idea, VsCode, etc.) than
>> the default one.
>>
> 
> 
> Thanks for sharing! I tried to use icomplete with “\n” separator, but encountered the problem that this package aims to solve. This should definitely be included as bugfix.

And it's definitely a very good step.

It would be even better if it could work with any of the packages that 
move minibuffer into a childframe. Unfortunately, the combination seems 
broken one way or another, probably because icomplete-vertical has to 
rely on a hack to get the right behavior.

E.g. with https://github.com/honmaple/emacs-maple-minibuffer I get:

Debugger entered--Lisp error: (error "Cannot resize a minibuffer-only 
frame")
   resize-mini-window-internal(#<window 6 on  *Minibuf-1*>)
   window--resize-mini-window(#<window 6 on  *Minibuf-1*> 36)
   enlarge-window(1)
   icomplete-vertical-minibuffer-setup()
   run-hooks(icomplete-minibuffer-setup-hook)
   icomplete-minibuffer-setup()

Re: "Why is emacs so square?"

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

  > > If the cursor keys work out of the box then the tutorial should
  > > begin with features which can be used without learning new cursor keys,
  > > demonstrating something which emacs does well or better than other
  > > tools.

I used to think it was important to teach Emacs cursor motion
character because they are needed to edit efficiently.  But if that
is a big discouragement to using the tutorial, let's try it another way.

  > Org mode, magit, helm comes to my mind.

"Org mode", as currently conceptualized (a single thing), is not
suitable to teach to beginners.  If we reconceptualize it as several
task-specific features, some of them may be useful to teach to
beginners.

Magit is not part of Emacs.  I would like to include it in Emacs.  A
year ago, its developer agreed to cooperate with getting the copyright
assignments; but last January, after I found a volunteer to do the
work of arranging this with contributors, the developer did not
respond.

Has anyone been in touch with him since then?  It would be very good
to get this moving.

I don't know what Helm's situation is (or what it does), but whether
describing it in Emacs is an option to consider depends on that
situation.

As a general matter, it is a lot more work to describe something with
a learn-by-doing tutorial than to describe it in a manual.  The number
of topics we can teach in the tutorial is thus limited.  The existing
tutorial does not talk about _any_ special purpose subsystems, not
even Dired, and I think it how it should be.

I think that people who reach the stage of starting using Dired
already know enough that they don't need a learn-by-doing tutorial to
learn it, and they might on the contrary find it annoyingly slow as a
way to learn.  That must go double for Magit.  The best way to tell
people how to use features like that is with ordinary manuals.

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

RE: "Why is emacs so square?"

[Drew Adams]

> I'd like to remind all of us that
> there's a lot of "propaganda" out there telling everyone to turn off
> GUI features such as the menu bar and the tool bar.  The network is
> full of personal init files that "proudly" do that, and forums like
> Reddit are full of such advice to every newbie who asks about
> configuring their Emacs.  It is hard to be enthusiastic about making
> these features more modern when the community seems to be divided on
> whether they should at all be present.  IMO, we should first get our
> act together and decide whether these features are important, and then
> speak up according to those decisions when we see advice to the
> contrary.

+1

And count me as one vote for the menu-bar being
important, especially for discoverability.  The
tool-bar is less important, IMO, but I'd still
vote to keep it.

Re: "Why is emacs so square?"

[Joseph Garvin]

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

I think part of the problem with things like the menu bar is that if you're
using emacs at all you are demonstrating a willingness to tolerate:

* A UI that doesn't look or behave like any other application
* Keyboard shortcuts inconsistent with every other application
* A bizarre ancient vocabulary inconsistent with every other application.
e.g. no Microsoft word user has ever considered themselves to have opened a
"buffer". They open "files". They move "windows" around, not "frames." They
cut and paste not kill and yank, etc.

You are basically making a commitment to being or becoming a power user. I
certainly would not have put up with it if I didn't think it was going to
save me a lot of time as a software developer (and it does, everyday). I
doubt anyone invests the mental effort to deal with learning emacs nowadays
unless this is their goal. If you just want to do "casual" text editing
emacs is a very weird choice in 2020.

If you're a new user the idea that seeing kill and yank in the menu bar as
options helps discoverablity doesn't really hold when already nothing is
named the way you expect or acts the way you expect. If you're an
experienced user, then I would guess that like me C-h f,v,k and blog posts
are 99% of your discoverablity experience.

On Thu, Apr 16, 2020, 9:58 AM Drew Adams <drew.adams@oracle.com> wrote:

> > I'd like to remind all of us that
> > there's a lot of "propaganda" out there telling everyone to turn off
> > GUI features such as the menu bar and the tool bar.  The network is
> > full of personal init files that "proudly" do that, and forums like
> > Reddit are full of such advice to every newbie who asks about
> > configuring their Emacs.  It is hard to be enthusiastic about making
> > these features more modern when the community seems to be divided on
> > whether they should at all be present.  IMO, we should first get our
> > act together and decide whether these features are important, and then
> > speak up according to those decisions when we see advice to the
> > contrary.
>
> +1
>
> And count me as one vote for the menu-bar being
> important, especially for discoverability.  The
> tool-bar is less important, IMO, but I'd still
> vote to keep it.
>
>

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Joseph Garvin <joseph.h.garvin@gmail.com>
> Date: Thu, 16 Apr 2020 10:34:24 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, emacs-devel@gnu.org, stefan@marxist.se, 
> 	ndame@protonmail.com
> 
> I think part of the problem with things like the menu bar is that if you're using emacs at all you are
> demonstrating a willingness to tolerate:
> 
> * A UI that doesn't look or behave like any other application
> * Keyboard shortcuts inconsistent with every other application
> * A bizarre ancient vocabulary inconsistent with every other application. e.g. no Microsoft word user has ever
> considered themselves to have opened a "buffer". They open "files". They move "windows" around, not
> "frames." They cut and paste not kill and yank, etc.
> 
> You are basically making a commitment to being or becoming a power user. I certainly would not have put
> up with it if I didn't think it was going to save me a lot of time as a software developer (and it does, everyday).
> I doubt anyone invests the mental effort to deal with learning emacs nowadays unless this is their goal. If you
> just want to do "casual" text editing emacs is a very weird choice in 2020.

That's definitely something we should keep in mind, but what on earth
does it have to do with turning off the GUI elements of the Emacs UI?
Or with the advice to newbies to turn them off?

> If you're a new user the idea that seeing kill and yank in the menu bar as options helps discoverablity doesn't
> really hold when already nothing is named the way you expect or acts the way you expect. If you're an
> experienced user, then I would guess that like me C-h f,v,k and blog posts are 99% of your discoverablity
> experience.

I suggest to take a good look at the menu bar, since we don't have
Kill and Yank there for a long time.  We have Cut and Copy and Paste
instead.

Re: "Why is emacs so square?"

[Marcin Borkowski]

On 2020-04-16, at 17:34, Joseph Garvin <joseph.h.garvin@gmail.com> wrote:

> [...] If you just want to do "casual" text editing
> emacs is a very weird choice in 2020.

Unless you came for Org-mode (though this might not be exactly "casual"
- but necessarily "power-user-ish" either).

Just my 2 cents,

-- 
Marcin Borkowski
http://mbork.pl

Re: "Why is emacs so square?"

[Ahmed Khanzada]

Joseph, a few things come to mind from reading your email:

1. Terminal-based Vim is not like a modern application, yet is more
popular than Emacs.

2. The audience for Emacs are people interested in using free
software and Lisp to extend their text editing experience. Very few of
these will be "casual editors", and in fact the FSF provides libre casual
editing software through the GNOME project.

3. If Emacs was to become a "modern" app tomorrow, an editor extended
in Lisp still only has appeal for a minority of programmers, much like
the Lisp language itself. Most programmers looking for easy and modern
experiences will likely stick with Atom and Sublime.

4. Most of the push for a "modern look" comes from the desire for Emacs
to play more nicely with proprietary platforms. Rather, the goal of
Emacs is to support platforms like GNU/Linux. Platforms that respect
your freedom, and also do not push a corporate UI/UX vision of "modernity".

(Perhaps if we do move forward with modernization, we should think of
modernization in the context of something like GNOME rather than MacOS
or Windows. Surely Emacs could be a better citizen of GNOME.)

5. Given that many of the people complaining about how Emacs looks are not
submitting patches to fix the problem themselves, resources would be diverted
from actual functionality to "modernity".

6. By the time we do major code refactoring "modernizing" Emacs on the
major proprietary platforms, what is "modern" has now once again
changed, and our resources were put towards a project with a poor return on
investment.

Basically, I don't see a "modernizing" project playing out well. We will
spend extensive time and energy on a moving target, and even if we
succeed, our Lisp-based vision still has limited appeal. Additionally, I
don't think "modernizing" Emacs advances the cause of free software,
given that there are other more popular casual libre tools for text editing
that individuals can use.

Re: "Why is emacs so square?"

[martin rudalics]

 > (Perhaps if we do move forward with modernization, we should think of
 > modernization in the context of something like GNOME rather than MacOS
 > or Windows. Surely Emacs could be a better citizen of GNOME.)

Citizenship goes both ways.  The absence of responses for

https://gitlab.gnome.org/GNOME/mutter/-/issues/840

sadly indicates that GNOME doesn't care much about us.

martin

Re: "Why is emacs so square?"

[ndame]

>
> Citizenship goes both ways. The absence of responses for
>
> https://gitlab.gnome.org/GNOME/mutter/-/issues/840
>
> sadly indicates that GNOME doesn't care much about us.
>

Gnome shell also has a development list. A way forward can
be to post to that list politely asking for a workaround until
the issue is solved:

https://mail.gnome.org/mailman/listinfo/gnome-shell-list

The developers may be more likely to respond if the asking
for help is sent to a discussion list.

Re: "Why is emacs so square?"

[Stefan Kangas]

Ahmed Khanzada <me@enzu.ru> writes:

> 1. Terminal-based Vim is not like a modern application, yet is more
> popular than Emacs.

How do you know that Vim is more popular than Emacs?

> 3. If Emacs was to become a "modern" app tomorrow, an editor extended
> in Lisp still only has appeal for a minority of programmers

I think features matters more than extension language to most users.
For example, the popularity of Vim is unlikely to be based on the
appeal of an editor extended in Vimscript.

> 4. Most of the push for a "modern look" comes from the desire for Emacs
> to play more nicely with proprietary platforms.

Why do you believe that to be the case?

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Ahmed Khanzada]

On Sat, 18 Apr 2020 16:02:35 -0700,
Stefan Kangas wrote:
> 
> Ahmed Khanzada <me@enzu.ru> writes:
> 
> > 1. Terminal-based Vim is not like a modern application, yet is more
> > popular than Emacs.
> 
> How do you know that Vim is more popular than Emacs?
>

https://insights.stackoverflow.com/survey/2019#development-environments-and-tools

Nearly 20% of programmers use vim, and around 3% use Emacs.

Visual Studio Code has 54%.

> > 3. If Emacs was to become a "modern" app tomorrow, an editor extended
> > in Lisp still only has appeal for a minority of programmers
> 
> I think features matters more than extension language to most users.
> For example, the popularity of Vim is unlikely to be based on the
> appeal of an editor extended in Vimscript.

That is fair enough. But for extensible editors, features are built by a
small group of folks interested in that sort of thing. A more
"mainstream" language usually means more extensions which means more features.

> 
> > 4. Most of the push for a "modern look" comes from the desire for Emacs
> > to play more nicely with proprietary platforms.
> 
> Why do you believe that to be the case?

I suppose this is a pure assumption on my part based on my anecdotal
experience. I hear more comments about Emacs not being a nice MacOS or
Windows application than a nice GNOME application, but that is just anecdotal
evidence, and is certainly skewed by the popularity of those platforms.

Re: "Why is emacs so square?"

[Po Lu]

Ahmed Khanzada <me@enzu.ru> writes:
> That is fair enough. But for extensible editors, features are built by a
> small group of folks interested in that sort of thing. A more
> "mainstream" language usually means more extensions which means more features.

I disagree.  The amount of extensions to an editor reflect the popularity
of the editor, not whether or not the editor's extension language is
"mainstream" or not.

Plus, Emacs Lisp has a bunch of nice goodies for Emacs, since the
language itself is seamlessly integrated with the editor it extends
(such as text properties in strings, buffer-local variables, et cetera).

I would also go as far as to say that writing Emacs programs is far
easier, and involves far less boilerplate, than writing extensions for,
say, VS Code:
-------------------------------------------------------------------------------
var setting: vscode.Uri = vscode.Uri.parse("untitled:" + "C:\summary.txt");
vscode.workspace.openTextDocument(setting).then((a: vscode.TextDocument) => {
    vscode.window.showTextDocument(a, 1, false).then(e => {
        e.edit(edit => {
            edit.insert(new vscode.Position(0, 0), "Your advertisement here");
        });
    });
}, (error: any) => {
    console.error(error);
    debugger;
});
------------------------------------versus------------------------------------
(with-current-buffer (find-file "~/summary.txt")
  (set-window-point (selected-window) (point-min))
  (insert "Your advertisement here"))
------------------------------------------------------------------------------

A better language wins extensions, not a "popular" language, and Emacs
Lisp is definitely more suited to extending editors than TypeScript.

Re: "Why is emacs so square?"

[Ahmed Khanzada]

On Sat, 18 Apr 2020 17:42:07 -0700,
> A better language wins extensions, not a "popular" language, and Emacs
> Lisp is definitely more suited to extending editors than TypeScript.

I certainly agree with everyone that Lisp is fantastic, and that
extending Emacs with Emacs Lisp is a great pleasure. And that Emacs Lisp
is certainly superior to any other alternative that I know of. So please
don't think I would want Emacs to use anything other than Lisp.

However, despite Lisp being extraordinarily powerful (truly a "better
language"), no dialect of Lisp is a top 10 language. It seems unlikely
to me that there is no correlation between that fact and the popularity
and accessibility of Emacs.

However, even if there is a correlation, determining the exact nature
and extent of correlation is difficult.

Re: "Why is emacs so square?"

[Po Lu]

Ahmed Khanzada <me@enzu.ru> writes:

> However, despite Lisp being extraordinarily powerful (truly a "better
> language"), no dialect of Lisp is a top 10 language. It seems unlikely
> to me that there is no correlation between that fact and the popularity
> and accessibility of Emacs.

Paul Graham has an insightful article here:
http://www.paulgraham.com/avg.html;  IMO, it's worth reading.

Plus, if you look inside the domain of "text editor extension
languages", Emacs Lisp is definitely one of the top-10 (assuming there
are 10 at all), and is also probably the most integrated one.

You can also extend Emacs in languages other than Emacs Lisp (the native
module support comes to mind), but at that point you're giving up
exactly what makes Emacs great.

> However, even if there is a correlation, determining the exact nature
> and extent of correlation is difficult.

Agreed.

Re: "Why is emacs so square?"

[ndame]

>
> A better language wins extensions, not a "popular" language, and Emacs
> Lisp is definitely more suited to extending editors than TypeScript.

I agree that Emacs is easier to program once you learned it, but
other editors, like VSCode, has the advantage that you don't have to
learn a quirky and unfamiliar language first.

Many developers know Javascript and even if one doesn't it's more similar
to mainstream languages than lisp, so extension writers mostly has to
learn the VSCode API only.

VScode has a very nice out of the box experience. If you want support
for a language then it's one click to install it and it installs the
necessary scaffolding too, like a language server for the language.

And it has Electron for display support which has a mature browser
engine behind it, so it can support advanced graphics features out
of the box on all the supported platforms.

Out of the box experience matters. Familiarity matters (e.g supporting
standard keys on the platfrom for cut and paste). Nice appearance matters.

No wonder lot of developers choose VScode:

https://trends.google.com/trends/explore?geo=US&q=emacs%20editor,visual%20studio%20code

Re: "Why is emacs so square?"

[Po Lu]

ndame <ndame@protonmail.com> writes:

> I agree that Emacs is easier to program once you learned it, but
> other editors, like VSCode, has the advantage that you don't have to
> learn a quirky and unfamiliar language first.

> Many developers know Javascript and even if one doesn't it's more similar
> to mainstream languages than lisp, so extension writers mostly has to
> learn the VSCode API only.

Here's the problem: You have to learn the VS Code API. I'd say learning
that, and becoming reasonably proficient at it takes longer than
skimming through the Emacs Lisp intro.

> VScode has a very nice out of the box experience. If you want support
> for a language then it's one click to install it and it installs the
> necessary scaffolding too, like a language server for the language.

We have several starter packs, with similarly nice OOTB experiences.
> And it has Electron for display support which has a mature browser
> engine behind it, so it can support advanced graphics features out
> of the box on all the supported platforms.

Electron is not free software (https://labs.parabola.nu/issues/1167),
and is definitely not as well suited to providing an integrated
experience like Emacs.

For instance, even if you render raw HTML inside VS Code, you would not
be able to grab the region using VSC APIs.  I'm not sure if the VSC API
allows interacting with the DOM, but from what I can tell, it can't.

There are also various other issues, with relying on a lower-level
abstraction for "nice graphics features" (the DOM) that is outside the
editors control.

> Out of the box experience matters. Familiarity matters (e.g supporting
> standard keys on the platfrom for cut and paste). Nice appearance matters.

We have Cua mode.  No, you don't need to have it enabled by default,
since it would result in unnecessary breakage for old users.  It would
be nice if the startup screen informed users of features such as the
(hypothetical) GTK theme previously mentioned, and Cua.

I personally think that the Emacs bindings are better, and in the end
work better with Emacs itself, but I do agree that newcomers should be
allowed to familiarize themselves with Emacs before moving their
workflow (and habits) to it entirely.

> No wonder lot of developers choose VScode:
> https://trends.google.com/trends/explore?geo=US&q=emacs%20editor,visual%20studio%20code

We're here to change that :)

Re: "Why is emacs so square?"

[Po Lu]

> And it has Electron for display support which has a mature browser
> engine behind it, so it can support advanced graphics features out
> of the box on all the supported platforms.

I'd like to add that even though Electron might have some fancier
features, I don't consider it more "mature" than the Emacs display
engine, which has had a 25+ year head start to "mature".

IIRC, some important concepts in the display engine have existed since
the era of AI Lab Emacs, which gives the display engine a nearly 40 year
head-start.

Perhaps we could focus on adding missing features to Emacs' display
engine (such as the aformentioned fancy graphics, and also some other
important features that RMS has mentioned, such as variable-pitch
indentation).

Plus, if we implement those features manually, we can make sure that
they work consistently well throughout all the supported platforms.
(Which is also what you get with Electron, etc).

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 19.04.2020 08:43, Po Lu wrote:
> Perhaps we could focus on adding missing features to Emacs' display
> engine (such as the aformentioned fancy graphics, and also some other
> important features that RMS has mentioned, such as variable-pitch
> indentation).

I'm pretty sure neither "fancy graphics" inside file buffers, nor 
variable-pitch indentation are the reason for VS Code's popularity.

Re: "Why is emacs so square?"

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I'm pretty sure neither "fancy graphics" inside file buffers, nor
> variable-pitch indentation are the reason for VS Code's popularity.

You have a point.  We need to figure out why VSC is so popular, and then
fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
probably counts in that area.

Re: "Why is emacs so square?"

[Bob Newell]

> You have a point.  We need to figure out why VSC is so popular, and then
> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
> probably counts in that area.

In both this and other messages, I get what you're saying and the goal
of making Emacs more accessible and more appealing is laudable and
ambitious, but definitely in the realm of possibility. (I think
/maybe/ some of the discussion is focused toward coding/software
development, and Emacs is much more than that, but I'll accept that
developers make up a big part of the actual and intended audience.)

But keep in mind that I'm old and grumpy and have used Emacs for
literally decades. When I started on Emacs back in the 80s, I knew
nothing. All I had used up to that point was a series of line-oriented
editors similar to 'ed'. Now (the question of graphics put aside in
that pre-graphics era), how did I learn Emacs? I went through the
tutorial carefully and fully. By the end of that I was a fledgling
Emacs user. It was enough for me to be able to do actual work.

Then, as I needed new things, I learned them. There was no internet so
I relied upon the Emacs manuals, which were and are very good
references. I picked up elisp as necessary. And it all worked out. Did
I jump right in and use Emacs out of the box? No. I knew I was making
a long-term investment in doing the tutorial, etc.

So here's the grumpy old man part: I sometimes think that today,
software is expected to fall into the instant gratification category.
A lot of users don't want to have to learn anything, they just want a
perfect out of the box experience. But I think those are conflicting
expectations.

Yes, make Emacs appealing and user friendly. But don't forget that a
masterful tool in the end requires mastery, which can't come for free.
I certainly draw the line at saying Emacs is for everyone. I'm not
saying it's only for some sort of snooty "elite" but I am saying that
it's for those who are willing to learn, seeing some extra work as the
aforementioned long-term investment, and who have the patience reach a
worthy goal a little later rather than right this very minute.


-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: "Why is emacs so square?"

[Po Lu]

Bob Newell <bobnewell@bobnewell.net> writes:

> But keep in mind that I'm old and grumpy and have used Emacs for
> literally decades. When I started on Emacs back in the 80s, I knew
> nothing. All I had used up to that point was a series of line-oriented
> editors similar to 'ed'. Now (the question of graphics put aside in
> that pre-graphics era), how did I learn Emacs? I went through the
> tutorial carefully and fully. By the end of that I was a fledgling
> Emacs user. It was enough for me to be able to do actual work.

I'm also old and grumpy, and I pretty much learned Emacs the same
way (and only about a decade after you did).
It would still be nice if we had a way for making Emacs easier for
today's lazy people to learn though.

> Then, as I needed new things, I learned them. There was no internet so
> I relied upon the Emacs manuals, which were and are very good
> references. I picked up elisp as necessary. And it all worked out. Did
> I jump right in and use Emacs out of the box? No. I knew I was making
> a long-term investment in doing the tutorial, etc.

I mostly agree, but the problem is a lot of people aren't willing to
make said investment due to prior prejudice, and you need a way to clear
that prejudice up.

> So here's the grumpy old man part: I sometimes think that today,
> software is expected to fall into the instant gratification category.
> A lot of users don't want to have to learn anything, they just want a
> perfect out of the box experience. But I think those are conflicting
> expectations.

Yes.
> Yes, make Emacs appealing and user friendly. But don't forget that a
> masterful tool in the end requires mastery, which can't come for free.
> I certainly draw the line at saying Emacs is for everyone. I'm not
> saying it's only for some sort of snooty "elite" but I am saying that
> it's for those who are willing to learn, seeing some extra work as the
> aforementioned long-term investment, and who have the patience reach a
> worthy goal a little later rather than right this very minute.

I'll keep that in mind.

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 20, 2020, at 13:34, Po Lu <luangruo@yahoo.com> wrote:
> 
> It would still be nice if we had a way for making Emacs easier for
> today's lazy people to learn though.

It is not that they are lazy, just like people who use a machine to do their laundry instead of doing it by hand, they use tools that have been developed without the historical constraints of Emacs.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

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

  > Yes, make Emacs appealing and user friendly. But don't forget that a
  > masterful tool in the end requires mastery, which can't come for free.
  > I certainly draw the line at saying Emacs is for everyone. I'm not
  > saying it's only for some sort of snooty "elite" but I am saying that
  > it's for those who are willing to learn, seeing some extra work as the
  > aforementioned long-term investment, and who have the patience reach a
  > worthy goal a little later rather than right this very minute.

+1.

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

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 20, 2020, at 7:53, Po Lu <luangruo@yahoo.com> wrote:
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> I'm pretty sure neither "fancy graphics" inside file buffers, nor
>> variable-pitch indentation are the reason for VS Code's popularity.
> 
> You have a point.  We need to figure out why VSC is so popular, and then
> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
> probably counts in that area.

LSP support out of the box


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 20.04.2020 02:39, Jean-Christophe Helary wrote:

>> You have a point.  We need to figure out why VSC is so popular, and then
>> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
>> probably counts in that area.

Probably. As well as better onboarding. Some better defaults as well.

> LSP support out of the box

We're basically already there:

- M-x package-install eglot
- C-x C-f ...
- M-x eglot

Re: "Why is emacs so square?"

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> We're basically already there:
>
> - M-x package-install eglot
> - C-x C-f ...
> - M-x eglot

Does Eglot have support for automatically downloading and installing
popular language servers (like lsp-mode does)? If it does, that would be nice.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 20.04.2020 07:35, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> We're basically already there:
>>
>> - M-x package-install eglot
>> - C-x C-f ...
>> - M-x eglot
> Does Eglot have support for automatically downloading and installing
> popular language servers (like lsp-mode does)? If it does, that would be nice.

Not thus far. Does VS Code do that?

Sounds like a good cause for a feature request. And if such an install 
script database is added, people should chip in and help maintaining that.

Re: "Why is emacs so square?"

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:


> Not thus far. Does VS Code do that?

Yes.  AFAICT their primary method for language support is the LSP
protocol (and LSP was also originally created for VS Code), and they
have an extension "marketplace" (closest anology here would be ELPA)
that has a nice way to install various language servers.

`lsp-mode' also has similar functionality.  It would be nice to have it
in eglot.

> Sounds like a good cause for a feature request. And if such an install
> script database is added, people should chip in and help maintaining
> that.

Agreed.

Re: "Why is emacs so square?"

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> >> You have a point.  We need to figure out why VSC is so popular, and then
> >> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
> >> probably counts in that area.
>
> Probably. As well as better onboarding. Some better defaults as well.

What does onboarding mean in this context?

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 12:10, Stefan Kangas wrote:
>>>> You have a point.  We need to figure out why VSC is so popular, and then
>>>> fill in the areas that Emacs is missing.  A mostly out-of-the-box setup
>>>> probably counts in that area.
>> Probably. As well as better onboarding. Some better defaults as well.
> What does onboarding mean in this context?

Maybe some improvements to the welcome screen. A better tutorial (which 
showcases advanced features, not just the "alien" part of Emacs) and/or 
some guides.

https://en.wikipedia.org/wiki/User_onboarding

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 24.04.2020 18:48, Dmitry Gutov wrote:
> A better tutorial (which showcases advanced features, not just the 
> "alien" part of Emacs)

VS Code's tutorial to compare: 
https://code.visualstudio.com/docs/introvideos/basics

(Yes, most of it is in a video; ours doesn't have to be but it's a 
decent approach; and we could do both a video and a text version).

Re: "Why is emacs so square?"

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

  > > Perhaps we could focus on adding missing features to Emacs' display
  > > engine (such as the aformentioned fancy graphics, and also some other
  > > important features that RMS has mentioned, such as variable-pitch
  > > indentation).

  > I'm pretty sure neither "fancy graphics" inside file buffers, nor 
  > variable-pitch indentation are the reason for VS Code's popularity.

That statement may be correct, but you've changed the topic.

You're talking specifically about VS Code, which is a "source code
editor".  What I had in mind, regarding variable-pitch text, was word
processing.

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

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 20.04.2020 05:19, 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. ]]]
> 
>    > > Perhaps we could focus on adding missing features to Emacs' display
>    > > engine (such as the aformentioned fancy graphics, and also some other
>    > > important features that RMS has mentioned, such as variable-pitch
>    > > indentation).
> 
>    > I'm pretty sure neither "fancy graphics" inside file buffers, nor
>    > variable-pitch indentation are the reason for VS Code's popularity.
> 
> That statement may be correct, but you've changed the topic.

Did I?

> You're talking specifically about VS Code, which is a "source code
> editor".  What I had in mind, regarding variable-pitch text, was word
> processing.

The topic was Emacs's popularity, AFAICT.

It's already a good source code editor, and yet its share among 
programmers is < 5%.

As a word processor, it's a lot less capable, and adding the two 
features you mentioned above won't bring us much closer to that goal, 
compared to established options. And there are existing Free programs 
that do this better already (like LibreOffice Writer).

We certainly should enable all kinds of uses, but given the limited 
resources, I think we should play to our strengths first.

Re: "Why is emacs so square?"

[Bob Newell]

> It's already a good source code editor, and yet its share among
> programmers is < 5%.

Interesting fact, I didn't know this and had assumed it was quite a bit higher.

> As a word processor, it's a lot less capable ... And there are existing Free programs
> that do this better already (like LibreOffice Writer).

You are right, there is LibreOffice, and I don't need Emacs to be
another WYSIWYG word processor.

But that said, it's already a terrific text processor, especially with
org-mode. I've written 8 novels in English, 1 in French, and countless
short stories with Emacs. I couldn't conceive of a more productive
writing tool, and in the writing community I know of many others who
feel the same way.

The AucTeX interface to LaTeX makes publishing feasible, too, although
I admit that's yet another learning curve to traverse.

-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 20.04.2020 08:07, Bob Newell wrote:

>> As a word processor, it's a lot less capable ... And there are existing Free programs
>> that do this better already (like LibreOffice Writer).
> 
> You are right, there is LibreOffice, and I don't need Emacs to be
> another WYSIWYG word processor.

I mean, new, optional, WYSIWYG modes wouldn't hurt, but they're unlikely 
to move the needle either.

> But that said, it's already a terrific text processor, especially with
> org-mode. I've written 8 novels in English, 1 in French, and countless
> short stories with Emacs. I couldn't conceive of a more productive
> writing tool, and in the writing community I know of many others who
> feel the same way.

Sure. And I've heard similar reports myself. But that's a more 
"specialized" kind of word processor. I don't know of better words to 
distinguish between the two.

Re: "Why is emacs so square?"

[Steinar Bang]

>>>>> Bob Newell <bobnewell@bobnewell.net>:

> But that said, it's already a terrific text processor, especially with
> org-mode. I've written 8 novels in English, 1 in French, and countless
> short stories with Emacs. I couldn't conceive of a more productive
> writing tool, and in the writing community I know of many others who
> feel the same way.

I haven't written any novels in it, but yeah, org-mode fills my text
processing needs as well (as well as being my notebook, time keeper and
more).

Re: "Why is emacs so square?"

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

  > I haven't written any novels in it, but yeah, org-mode fills my text
  > processing needs as well (as well as being my notebook, time keeper and
  > more).

When I write a pamphlet using Libre Office, I need to see how it
will appear on the page.  I need to see where line breaks and paragraph
breaks appear.

I want Emacs to be able to do tect processing that way.

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

Re: "Why is emacs so square?"

[Arthur Miller]

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 haven't written any novels in it, but yeah, org-mode fills my text
>   > processing needs as well (as well as being my notebook, time keeper and
>   > more).
>
> When I write a pamphlet using Libre Office, I need to see how it
> will appear on the page.  I need to see where line breaks and paragraph
> breaks appear.
>
> I want Emacs to be able to do tect processing that way.
When you say page, you mean a printed page on paper?

Can't that be helped with some of live preview options for a pdf or ps
or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?

Or couldn't it be possible to define some html+css to model A4 paper
size, for example:

https://codepen.io/rafaelcastrocouto/pen/LFAes

and use some of live preview options for html (eww or browseurl or
something else)? Not a wysiwyg directly, but kind-of middle ground?

Re: "Why is emacs so square?"

[Juri Linkov]

> Or couldn't it be possible to define some html+css to model A4 paper
> size, for example:
>
> https://codepen.io/rafaelcastrocouto/pen/LFAes
>
> and use some of live preview options for html (eww or browseurl or
> something else)? Not a wysiwyg directly, but kind-of middle ground?

Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
      --run-all-compositor-stages-before-draw --no-margins doc.html
or using its wrapper chromehtml2pdf.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Juri Linkov <juri@linkov.net> writes:
> Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
>       --run-all-compositor-stages-before-draw --no-margins doc.html
> or using its wrapper chromehtml2pdf.

there are alternatives which don't require malware:

   abiword --to=PDF -o a.pdf a.html
   soffice --headless --convert-to pdf a.html
   wkhtmltopdf -B 24 -L 24 -R 24 -T 24 a.html a.pdf

But none of those produce good documents.

As an experiment, I tried to produce the ebooks.pdf document from
org-mode, exported to html, opened in firefox, printed to pdf.  It gave
the best result.  It looked almost like the original and was easy to
tune in org-mode.  I only had to iterate a few times.

But still, all these solutions require huge dependencies.

Re: "Why is emacs so square?"

[Juri Linkov]

>> Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
>>       --run-all-compositor-stages-before-draw --no-margins doc.html
>> or using its wrapper chromehtml2pdf.
>
> there are alternatives which don't require malware:

BTW, why browse-url.el still doesn't support the Brave web browser?
Brave solved the problem of malware.  It's one of the most secure
and privacy-respecting web browsers.  Unless someone presents a reason
not to do this, I'm going to add Brave support to browse-url.el.

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Jun 7, 2020, at 8:30, Juri Linkov <juri@linkov.net> wrote:
> 
>>> Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
>>>      --run-all-compositor-stages-before-draw --no-margins doc.html
>>> or using its wrapper chromehtml2pdf.
>> 
>> there are alternatives which don't require malware:
> 
> BTW, why browse-url.el still doesn't support the Brave web browser?
> Brave solved the problem of malware.  It's one of the most secure
> and privacy-respecting web browsers.  Unless someone presents a reason
> not to do this, I'm going to add Brave support to browse-url.el.

A piece of software that actively promotes cryptocurrency use is a scam. But maybe that's not a valid reason.

-- 
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
writes:

>> On Jun 7, 2020, at 8:30, Juri Linkov <juri@linkov.net> wrote:
>> 
>>>> Maybe chromium-browser --print-to-pdf=doc.pdf --headless --disable-gpu
>>>>      --run-all-compositor-stages-before-draw --no-margins doc.html
>>>> or using its wrapper chromehtml2pdf.
>>> 
>>> there are alternatives which don't require malware:
>> 
>> BTW, why browse-url.el still doesn't support the Brave web browser?
>> Brave solved the problem of malware.  It's one of the most secure
>> and privacy-respecting web browsers.  Unless someone presents a reason
>> not to do this, I'm going to add Brave support to browse-url.el.
>
> A piece of software that actively promotes cryptocurrency use is a
> scam.

agree

- cryptocurency burns the world

- investors behind the brave browser seem questionable

for example, today surfaced how the brave browser is hijacking links

it seems to be malware with good marketing to fool people

RE: "Why is emacs so square?"

[Drew Adams]

> BTW, why browse-url.el still doesn't support the Brave web browser?
> Brave solved the problem of malware.  It's one of the most secure
> and privacy-respecting web browsers.  Unless someone presents a reason
> not to do this, I'm going to add Brave support to browse-url.el.

+1 for Brave browser.

Re: "Why is emacs so square?"

[Yuri Khan]

On Sun, 7 Jun 2020 at 06:55, Juri Linkov <juri@linkov.net> wrote:

> BTW, why browse-url.el still doesn't support the Brave web browser?
> Brave solved the problem of malware.  It's one of the most secure
> and privacy-respecting web browsers.  Unless someone presents a reason
> not to do this, I'm going to add Brave support to browse-url.el.

But it’s not free software.

Re: "Why is emacs so square?"

[Yuri Khan]

On Sun, 7 Jun 2020 at 14:51, Yuri Khan <yuri.v.khan@gmail.com> wrote:
>
> On Sun, 7 Jun 2020 at 06:55, Juri Linkov <juri@linkov.net> wrote:
>
> > BTW, why browse-url.el still doesn't support the Brave web browser?
> > Brave solved the problem of malware.  It's one of the most secure
> > and privacy-respecting web browsers.  Unless someone presents a reason
> > not to do this, I'm going to add Brave support to browse-url.el.
>
> But it’s not free software.

Or is it, huh.[^1] For some reason, the FAQ on the main site[^2] has
the question “Is Brave free?”, and the answer only talks about
free-as-in-beer. To find out about the free-as-in-freedom aspect, you
have to notice the Github link in the footer.

[^1]: https://github.com/brave/brave-browser/blob/master/LICENSE
[^2]: https://brave.com/

Re: "Why is emacs so square?"

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

ISTR that Brave _is_ free software, but has a malfeature.
So we would not want to propose its use.

I've been misinformed about this before -- we would want someone
to check carefully.

Someone could make a modified version without that.  Does this exist?

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

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 07.06.2020 02:30, Juri Linkov wrote:
> BTW, why browse-url.el still doesn't support the Brave web browser?
> Brave solved the problem of malware.  It's one of the most secure
> and privacy-respecting web browsers.

Not so sure about that:

https://news.ycombinator.com/item?id=23442027

RE: "Why is emacs so square?"

[Drew Adams]

> > BTW, why browse-url.el still doesn't support the Brave web browser?
> > Brave solved the problem of malware.  It's one of the most secure
> > and privacy-respecting web browsers.
> 
> Not so sure about that:
> 
> https://urldefense.com/v3/__https://news.ycombinator.com/item?id=23442027__;!
> !GqivPVa7Brio!PGyydJ9-LLd8XIznjSJYn6c7uA9nqpwscDwdwqEeZPfto_aWii9FMcJ-
> c7L01E0p$

Thanks for that link.  Interesting discussion.
I'm no expert on these things, but this remark
there seems relevant:

  "Brave ads are opt-in, for people who would like
   to earn "shitty" cryptocurrency by clicking on them."

I opted out, at the outset.  Perhaps I'm not aware
of some other behind-the-scenes behavior that's
problematic.  I didn't read all of the page you
link to in detail, but my (maybe naive) impression
is that if you opt out of ads that pretty much
takes care of things.

The only technical problem I've encountered with
Brave, compared to Google Chrome, is that some
dropdown/pulldown lists on some sites don't work.

Re: "Why is emacs so square?"

[Juri Linkov]

>> BTW, why browse-url.el still doesn't support the Brave web browser?
>> Brave solved the problem of malware.  It's one of the most secure
>> and privacy-respecting web browsers.
>
> Not so sure about that:
>
> https://news.ycombinator.com/item?id=23442027

Oh, I thought it would be a good option.

Re: "Why is emacs so square?"

[Stefan Monnier]

> BTW, why browse-url.el still doesn't support the Brave web browser?

I know nothing about Brave, but I'm wondering instead why it is that
browse-url.el would need special support for specific browsers.
Can't it just run "the" browser, whichever it is?


        Stefan

Re: "Why is emacs so square?"

[Basil L. Contovounesios]

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

>> BTW, why browse-url.el still doesn't support the Brave web browser?
>
> I know nothing about Brave, but I'm wondering instead why it is that
> browse-url.el would need special support for specific browsers.
> Can't it just run "the" browser, whichever it is?

Doesn't browse-url-default-browser try to DTRT already?

-- 
Basil

Re: "Why is emacs so square?"

[Juri Linkov]

>> BTW, why browse-url.el still doesn't support the Brave web browser?
>
> I know nothing about Brave, but I'm wondering instead why it is that
> browse-url.el would need special support for specific browsers.
> Can't it just run "the" browser, whichever it is?

There is a lot of cruft accumulated in browse-url.el mostly for old browsers
with different handling of command line arguments for "new-window-is-tab" logic.
But it seems nowadays only three options should be sufficient:

- use the default browser found by browse-url-default-browser;
- or use Emacs browser eww;
- or allow to specify a browser program name with additional arguments.

Re: "Why is emacs so square?"

[andres.ramirez]

Hi Juri.

>>>>> "Juri" == Juri Linkov <juri@linkov.net> writes:

    Juri> nowadays only three options should be sufficient:

    Juri> - use the default browser found by browse-url-default-browser;
    Juri> - or use Emacs browser eww;

Or use emacs not default browser (w3m). Not default browser. But
arguably has more features.

    Juri> - or allow to specify a browser program name with additional arguments.

Best Regards

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Jun 8, 2020, at 7:31, Juri Linkov <juri@linkov.net> wrote:
> 
>>> BTW, why browse-url.el still doesn't support the Brave web browser?
>> 
>> I know nothing about Brave, but I'm wondering instead why it is that
>> browse-url.el would need special support for specific browsers.
>> Can't it just run "the" browser, whichever it is?
> 
> There is a lot of cruft accumulated in browse-url.el mostly for old browsers
> with different handling of command line arguments for "new-window-is-tab" logic.
> But it seems nowadays only three options should be sufficient:
> 
> - use the default browser found by browse-url-default-browser;
> - or use Emacs browser eww;
> - or allow to specify a browser program name with additional arguments.

That makes sense.

-- 
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com

Re: "Why is emacs so square?"

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

  > > When I write a pamphlet using Libre Office, I need to see how it
  > > will appear on the page.  I need to see where line breaks and paragraph
  > > breaks appear.
  > >
  > > I want Emacs to be able to do tect processing that way.
  > When you say page, you mean a printed page on paper?

Of course.  A pamphlet is for handing out.

  > Can't that be helped with some of live preview options for a pdf or ps
  > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?

It would probably take half a minute each time.  I am sure you
understand the advantage of WYSIWYG.  Especially when the text needs
to fit in a limited space.

This is not an issue for longer documents, since it doesn't crucially matter
where the page breaks are in those.

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

Re: "Why is emacs so square?"

[Marcin Borkowski]

On 2020-06-05, at 05:12, Richard Stallman <rms@gnu.org> wrote:

>   > Can't that be helped with some of live preview options for a pdf or ps
>   > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?
>
> It would probably take half a minute each time.  I am sure you
> understand the advantage of WYSIWYG.  Especially when the text needs
> to fit in a limited space.

I think you made a typo here, it should have been "half a second"
probably.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: "Why is emacs so square?"

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

  > >   > Can't that be helped with some of live preview options for a pdf or ps
  > >   > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?
  > >
  > > It would probably take half a minute each time.

  > I think you made a typo here, it should have been "half a second"
  > probably.

That would be an amazing typo.  I expect starting these various
programs to take a long time.  But if it doesn't, they might
be adequate.



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

Re: "Why is emacs so square?"

[Arthur Miller]

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. ]]]
>
>   > >   > Can't that be helped with some of live preview options for a pdf or ps
>   > >   > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?
>   > >
>   > > It would probably take half a minute each time.
>
>   > I think you made a typo here, it should have been "half a second"
>   > probably.
>
> That would be an amazing typo.  I expect starting these various
> programs to take a long time.  But if it doesn't, they might
> be adequate.
I don't know what kind of computer you use, of course, but if you ment
the startup time for a browser, then maybe it is a half second or so, but
does it matter? It happends once, when one start to work on a pamflet.
LibreOffice takes also a half a second if not more to startup every time
and I have quite decent machine.

If you start a Chromium process, and then connect from within Emacs with
impatient-mode, I don't think you would suffer from lack of real time
performance; not for something like a pamflet.

Another option is to use some webkit wrap + xwidgets, but I haven't
tryed it myself. No idea how easy to use or good it is, but for preview
it should probably be good enough. I have seen some Reddit threads
and YT videos where people demonstrated it, but I didn't care to try
myself.

Here is some 4 year old video where a guy is demonstrating xwidgets and
webkit to render html in gnus:

https://www.youtube.com/watch?v=J2YdjpWJJHs

(download with youtube-dl to skip proprietary js)

Very nice presentation by the way.

With HTML+CSS as intermediate file format, one can have some predefined
templates with a pamflet size, layout, typografi etc, and then just edit
content of few html tags.

Re: "Why is emacs so square?"

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

The process that was suggested for viewing the page image
involved running several programs each time.  A few seconds to start each
and it could take half a minute.

I use a machine that was made in 2008 or so.  I use it because we can
boot it with libreboot.  I cannot predict when there might be a faster
machine I could use.

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

Re: "Why is emacs so square?"

[Arthur Miller]

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 process that was suggested for viewing the page image
> involved running several programs each time.  A few seconds to start each
> and it could take half a minute.
>
> I use a machine that was made in 2008 or so.  I use it because we can
> boot it with libreboot.  I cannot predict when there might be a faster
> machine I could use.
I understand.

Have you heard about company called Purism and librem project?

https://puri.sm/why-purism/

I am not sure if it is suitable enough, but they do run only free
software, from boot (coreboot) to highest level; at least as I understand
them. Also I believe they went to the length of ordering Intel cpus with
intel's "management" backdoor disabled. Just as a tip.

Re: "Why is emacs so square?"

[Arthur Miller]

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. ]]]
>
>   > > When I write a pamphlet using Libre Office, I need to see how it
>   > > will appear on the page.  I need to see where line breaks and paragraph
>   > > breaks appear.
>   > >
>   > > I want Emacs to be able to do tect processing that way.
>   > When you say page, you mean a printed page on paper?
>
> Of course.  A pamphlet is for handing out.
>
>   > Can't that be helped with some of live preview options for a pdf or ps
>   > or latex format? Auctex maybe? Or maybe some of org -> pdf/ps + DocView?
>
> It would probably take half a minute each time.  I am sure you
> understand the advantage of WYSIWYG.  Especially when the text needs
> to fit in a limited space.
I understand that wysiwyg is easier and I understand your concern
for delays. I believe those delays would not be noticable for a pamphlet
(A4/A5 size?) if you used html as intermediate format.

Anyway what about if emacs had a print-page-mode as a minor mode for
displaying some printing hints in text modes? I am not sure if I can
write such, but here is idea:

* provide a database of predefined paper sizes as specified on:
  https://www.papersizes.org/a-sizes-in-pixels.htm
  to be used as templates for width and height (in pixels)
  
* advice insert funcion(s) to check for current line pixel-width and
  pixel-height. If width or height exceed template width and height then
  insert ^L to denote page break and move point to next line and insert
  text in next line. If width is exceeded maybe it is just enough to
  move point to next line, but when height for a page is exceeded one
  would need a special char to visualize page break.

As I understand Emacs already has some support for page breaks (^L) as I
learned myself very recently :-). There is extended page handling in
Emacs and also a mode called PageMode:

https://www.emacswiki.org/emacs/PageMode

I am not sure, but what I think is missing is just to tie those things
to paper sizes and automize page creation based on some paper template
which is nothing but a pixel-width and pixel-height. I am not sure, I
haven't used PageMode myself, I just learned about it.

I am not sure how efficient it would be to check for pixel-width and height
on every char insertion, maybe there is some better way?

It would be nice if Emacs could draw a thin line to denote edges, or a
rectangle of page size below the text as word processors do, but that
would ask for some c and exposing of some graphics (XDrawRect & co) to
elisp?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Fri, 05 Jun 2020 15:01:13 +0200
> Cc: sb@dod.no, emacs-devel@gnu.org
> 
> Anyway what about if emacs had a print-page-mode as a minor mode for
> displaying some printing hints in text modes? I am not sure if I can
> write such, but here is idea:
> 
> * provide a database of predefined paper sizes as specified on:
>   https://www.papersizes.org/a-sizes-in-pixels.htm
>   to be used as templates for width and height (in pixels)
>   
> * advice insert funcion(s) to check for current line pixel-width and
>   pixel-height. If width or height exceed template width and height then
>   insert ^L to denote page break and move point to next line and insert
>   text in next line. If width is exceeded maybe it is just enough to
>   move point to next line, but when height for a page is exceeded one
>   would need a special char to visualize page break.
> 
> As I understand Emacs already has some support for page breaks (^L) as I
> learned myself very recently :-). There is extended page handling in
> Emacs and also a mode called PageMode:
> 
> https://www.emacswiki.org/emacs/PageMode
> 
> I am not sure, but what I think is missing is just to tie those things
> to paper sizes and automize page creation based on some paper template
> which is nothing but a pixel-width and pixel-height. I am not sure, I
> haven't used PageMode myself, I just learned about it.
> 
> I am not sure how efficient it would be to check for pixel-width and height
> on every char insertion, maybe there is some better way?

All of this is already available, although not all of it is exposed to
Lisp.  Taking advantage of existing pixel-level capabilities is part
of the job of providing the features that Richard has in mind.

> It would be nice if Emacs could draw a thin line to denote edges, or a
> rectangle of page size below the text as word processors do

We already can display such thin lines, see, for example, help-fns.el
(search for ":height").  No X-level graphics is needed.

Re: "Why is emacs so square?"

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Fri, 05 Jun 2020 15:01:13 +0200
>> Cc: sb@dod.no, emacs-devel@gnu.org
>> 
>> Anyway what about if emacs had a print-page-mode as a minor mode for
>> displaying some printing hints in text modes? I am not sure if I can
>> write such, but here is idea:
>> 
>> * provide a database of predefined paper sizes as specified on:
>>   https://www.papersizes.org/a-sizes-in-pixels.htm
>>   to be used as templates for width and height (in pixels)
>>   
>> * advice insert funcion(s) to check for current line pixel-width and
>>   pixel-height. If width or height exceed template width and height then
>>   insert ^L to denote page break and move point to next line and insert
>>   text in next line. If width is exceeded maybe it is just enough to
>>   move point to next line, but when height for a page is exceeded one
>>   would need a special char to visualize page break.
>> 
>> As I understand Emacs already has some support for page breaks (^L) as I
>> learned myself very recently :-). There is extended page handling in
>> Emacs and also a mode called PageMode:
>> 
>> https://www.emacswiki.org/emacs/PageMode
>> 
>> I am not sure, but what I think is missing is just to tie those things
>> to paper sizes and automize page creation based on some paper template
>> which is nothing but a pixel-width and pixel-height. I am not sure, I
>> haven't used PageMode myself, I just learned about it.
>> 
>> I am not sure how efficient it would be to check for pixel-width and height
>> on every char insertion, maybe there is some better way?
>
> All of this is already available, although not all of it is exposed to
> Lisp.  Taking advantage of existing pixel-level capabilities is part
> of the job of providing the features that Richard has in mind.
When you say all of this, and not exposed to lisp, what exactly do you
mean? :-) Is it possible to get a pixel offset from a point with elisp?
Height, width, or whatever that could be used to calculate if current
buffer region fits iin a page or not?

(defvar ppi-72
  '((4A0 . (4768 . 6741))
    (2A0 . (3370 . 4768))
    (A0  . (2384 . 3370))
    (A1  . (1684 . 2384))
    (A2  . (1191 . 1684))
    (A3  . (842  . 1191))
    (A4  . (595  . 842 ))
    (A5  . (420  . 595 ))
    (A6  . (298  . 420 ))
    (A7  . (210  . 298 ))
    (A8  . (147  . 210 ))
    (A9  . (105  . 147 ))
    (A10 . (74   . 105 ))))

If I have a database of sizes like this, I would need to know a size in
pixel of a buffer region between some min and max points. That could be
used to either defadvice insert or to calculate and restructure text
afterwards. Maybe it is to naive, no idea, just thinking. Also I am not
sure how resolution/ppi relate to emacs buffers to be honest.


>> It would be nice if Emacs could draw a thin line to denote edges, or a
>> rectangle of page size below the text as word processors do
>
> We already can display such thin lines, see, for example, help-fns.el
> (search for ":height").  No X-level graphics is needed.
As composed of characters or as overlays with underline/overstruck or
similar? What about a rectangle in some color as a background to
symbolize a page. I understand it is not needed, but it would be nice.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: rms@gnu.org,  sb@dod.no,  emacs-devel@gnu.org
> Date: Fri, 05 Jun 2020 16:57:32 +0200
> 
> > All of this is already available, although not all of it is exposed to
> > Lisp.  Taking advantage of existing pixel-level capabilities is part
> > of the job of providing the features that Richard has in mind.
> When you say all of this, and not exposed to lisp, what exactly do you
> mean? :-) Is it possible to get a pixel offset from a point with elisp?
> Height, width, or whatever that could be used to calculate if current
> buffer region fits iin a page or not?

See window-text-pixel-size as one example of what we have.  The
underlying functionality is even more powerful.

> >> It would be nice if Emacs could draw a thin line to denote edges, or a
> >> rectangle of page size below the text as word processors do
> >
> > We already can display such thin lines, see, for example, help-fns.el
> > (search for ":height").  No X-level graphics is needed.
> As composed of characters or as overlays with underline/overstruck or
> similar?

Just look at the code, it is self-explanatory, IMO.

> What about a rectangle in some color as a background to symbolize a
> page.

You will see in the code I pointed to that we actually already produce
a rectangle, just a very thin one.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Eli Zaretskii <eliz@gnu.org> writes:
> See window-text-pixel-size as one example of what we have.  The
> underlying functionality is even more powerful.

(window-text-pixel-size) returns nonsense in console.

>> > We already can display such thin lines, see, for example, help-fns.el
>> > (search for ":height").  No X-level graphics is needed.

X graphics is seems to be needed.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: sb@dod.no, rms@gnu.org, emacs-devel@gnu.org
> Date: Fri, 05 Jun 2020 18:15:50 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > See window-text-pixel-size as one example of what we have.  The
> > underlying functionality is even more powerful.
> 
> (window-text-pixel-size) returns nonsense in console.

It does?  Can you show an example?  Or, better yet, make a bug report
about the problematic case(s)?

> >> > We already can display such thin lines, see, for example, help-fns.el
> >> > (search for ":height").  No X-level graphics is needed.
> 
> X graphics is seems to be needed.

You need a GUI frame (not necessarily on X), but that's all.  There's
no need to expose Xlib calls to Lisp, which was what the original
question was about.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Eli Zaretskii <eliz@gnu.org> writes:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > See window-text-pixel-size as one example of what we have.  The
>> > underlying functionality is even more powerful.
>> 
>> (window-text-pixel-size) returns nonsense in console.
>
> It does?  Can you show an example?  Or, better yet, make a bug report
> about the problematic case(s)?

bug report sent

>> >> > We already can display such thin lines, see, for example, help-fns.el
>> >> > (search for ":height").  No X-level graphics is needed.
>> 
>> X graphics is seems to be needed.
>
> You need a GUI frame (not necessarily on X), but that's all.  There's
> no need to expose Xlib calls to Lisp, which was what the original
> question was about.

ok, thanks for clarification

Re: "Why is emacs so square?"

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

  > I understand that wysiwyg is easier and I understand your concern
  > for delays. I believe those delays would not be noticable for a pamphlet
  > (A4/A5 size?) if you used html as intermediate format.

Could you state your proposed solution more concretely?
How would it work, which programs would it use?

  > * provide a database of predefined paper sizes as specified on:
  >   https://www.papersizes.org/a-sizes-in-pixels.htm
  >   to be used as templates for width and height (in pixels)
  
  > * advice insert funcion(s) to check for current line pixel-width and
  >   pixel-height. If width or height exceed template width and height then
  >   insert ^L to denote page break and move point to next line and insert
  >   text in next line. If width is exceeded maybe it is just enough to
  >   move point to next line, but when height for a page is exceeded one
  >   would need a special char to visualize page break.

If this works reliably, and isn't very slow, it could be good enough.
For this to work reliably requires understanding the width of text
as it will eventually be rendered, including different sizes and
variants (italic, bold, etc).

  > I am not sure how efficient it would be to check for pixel-width and height
  > on every char insertion, maybe there is some better way?

We can arrange to take note of how wide the line is,
update that incrementally in a quick way, then do more
processing when that seems necessary.

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 05 Jun 2020 23:56:16 -0400
> Cc: sb@dod.no, emacs-devel@gnu.org
> 
>   > * advice insert funcion(s) to check for current line pixel-width and
>   >   pixel-height. If width or height exceed template width and height then
>   >   insert ^L to denote page break and move point to next line and insert
>   >   text in next line. If width is exceeded maybe it is just enough to
>   >   move point to next line, but when height for a page is exceeded one
>   >   would need a special char to visualize page break.
> 
> If this works reliably, and isn't very slow, it could be good enough.
> For this to work reliably requires understanding the width of text
> as it will eventually be rendered, including different sizes and
> variants (italic, bold, etc).

FWIW, I don't think this is possible from Lisp, not with the currently
available facilities.  shr.el does something like that, and it does a
decent job with the tools it has, but IMO it is nowhere near what is
needed, and cannot handle complex situations with various complex
scripts.  It is also quite slow: I sometimes need to wait for several
seconds for it to display an email message of a couple of hundreds
lines.

Layout in Emacs has to be done in C to be both efficient and fully
capable.  Some small and simple jobs, like pixel-level alignment, can
be done in Lisp, but not the entire job as a whole.

Re: "Why is emacs so square?"

[Bob Newell]

Richard Stallman <rms@gnu.org> writes:

> This is not an issue for longer documents, since it doesn't crucially
> matter
> where the page breaks are in those.

Just as a point of interest: page breaks definitely can matter
in longer documents. I've done quite a number of books with
Emacs/LaTeX, and in doing text layout I have to take into
account widows and orphans--- for instance, having a single
line of a paragraph at the bottom of a page is a no-no, and
page breaks have to be manipulated to avoid bad typography.

That said, I've found that even for longish books with many
diagrams (my most extreme example was nearly 800 pages), the
compile and view process was fast enough not to get in the
way, and corrections and changes go very fast if using
something like synctex (I believe that's the correct name).

This is not to say that I don't see the need for WYSIWYG on
graphics-intense publications; for instance I couldn't see
doing a comic book in emacs.

-- 
Bob Newell
Honolulu, Hawai`i

- Via GNU/Linux/Emacs/Gnus/BBDB

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Richard Stallman <rms@gnu.org> writes:
> When I write a pamphlet using Libre Office, I need to see how it
> will appear on the page.  I need to see where line breaks and paragraph
> breaks appear.
>
> I want Emacs to be able to do tect processing that way.

What are the missing pieces?

I think there are many and they would be useful for other use-cases.

Some of the use-cases I am interested in:

1) Sometimes, I need to write a letter which does not need to be an art
   work.  I wrote emacs-pdf (see
   <https://logand.com/sw/emacs-pdf/file/emacs-pdf.el.html>) to address
   that.

   It creates a PDF document from an Emacs buffer.  Only plain,
   monospace ASCII text works so far, but it can already break and count
   pages and insert headers and footers.  It is very short (about 400
   lines of elisp including comments) and requires no dependencies and
   no graphics.

   a) The next step will be unicode.

      It seems that there is some code in Emacs dealing with unicode
      fonts in order to generate postscript files.  Any pointers where
      to start with this?
  
   b) After that, emacs-pdf will understand font metrics so it will be
      possible to do layout.

      It should be possible to render HTML for example, and create
      graphical web browser as an alternative to eww.

      It should also be possible to render other formats like abw, odt,
      etc.  At least roughly, depending on how much detail in the
      corresponding spec people want to address.  I have explored simple
      conversion to text in pure elisp in emacs-unoffice
      <https://logand.com/sw/emacs-unoffice/file/emacs-unoffice.el.html>.

      It should be possible to write a direct PDF backend for org-mode
      and maybe enriched-mode.

      Internally, probably some kind of html like sexp based format
      should be used.  I used a sexp based format in emacs-pdf
      (transient cons tree representation) but for document processing,
      the format should not be so low level (e.g. no PDF drawing
      primitives but something like HTML primitives; or maybe mixed).

   c) It should not be difficult to add raster images and vector
      graphics to the PDF drawing code.

   d) It should be possible to add for example SVG backend.  Non-console
      Emacs can already draw SVG.  At least at the beginning, this would
      also avoid the need for image rasterisation if vector format like
      PDF or SVG is used.

      Maybe this could be used for real-time preview, before we get
      WYSIWYG.  Or maybe use pdf-tools to view the generated PDF.

2) Printing is an issue in Emacs.  I will try to implement an
   alternative which will use IPP and PDF.  No PostScript, no CUPS, if
   possible no complex configuration.

3) I use Emacs on the console a lot.  All the above should work there
   too.  In order to view images in console Emacs, I wrote
   <https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html>.
   So far there are a few functions that draw images using w3mimgdisplay
   from the w3m console web browser.  It fits images on the screen,
   unlike graphical Emacs where image display is unuseable.

   a) I would like image-mode just work with this emacs-framebuffer
      image drawing.  Any ideas, how to plug emacs-framebuffer into
      image-mode?

   b) It is a shame, that I need to reimplement such basic functions
      like image-size:

      (image-size (create-image "/tmp/a.jpg"))
      => (error "Window system frame should be used")

      framebuffer-image-size at
      https://logand.com/sw/emacs-framebuffer/file/emacs-framebuffer.el.html#l95
      does not require any dependencies and computes image size for png,
      jpeg, bmp, gif, tiff and pnm in elisp.

      It would be nice to eliminate or at least reduce the need for such
      dependencies so that many Emacs features are useable in different
      environments, like for example console.

   c) There are functions frame-width and frame-height.  Are there also
      functions something like buffer-width and buffer-height and or a
      way to compute x and y position relative to frame origin, which
      would allow me to position images exactly in the buffer similar to
      what w3m browser does?

4) Emacs is missing some kind of canvas, where things could be drawn and
   which would handle pixel precise input.

   For example, I would like to browse OpenStreetMap in Emacs.  I wrote
   a console based OSM browser osmq
   <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
   <https://osmq.eu/>.  I would prefer an Emacs based map browser.
   However, I have not figured out how to lay out images in Emacs in a
   grid and how to detect which image was clicked.  A bonus would be,
   where exactly was clicked.  Any ideas what should I look into?

   Emacs canvas should probably work like HTML canvas, which is rather
   similar to PDF or PostScript in terms of drawing interface.  I have
   explored this space in the PostScript interpreter in JavaScript
   <https://logand.com/sw/wps/index.html>.

   Not sure how difficult it would be to plug some kind of portable
   canvas into Emacs.  This seems rather low level C work.

It seems to me that these points are precondition for a WYSIWYG document
editor feature in Emacs.

Do these points resonate here?

Is somebody already implementing anything mentioned?

Or what is already implemented?

Would there be an interest in incorporating emacs-pdf, emacs-unoffice
and emacs-framebuffer (the framebuffer-image-size function?) into Emacs?

Regards,

Tomas

Re: "Why is emacs so square?"

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

Better exporting of Emacs buffers to PDF is certainly a desirable feature.
Any system for editing formatted text in Emacs will need that feature.

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Fri, 05 Jun 2020 23:54:08 +0200
> Cc: emacs-devel@gnu.org
> 
>       It seems that there is some code in Emacs dealing with unicode
>       fonts in order to generate postscript files.  Any pointers where
>       to start with this?

I think you should provide more details about the particular problem
you are trying to solve here, because I don't think I understand it.
Emacs generally knows only about fonts it uses for its own display,
and it needs to load the font before it can provide information about
it.  Whereas you seem to be talking about fonts to be used in the PDF
file, not in Emacs display.

>    b) After that, emacs-pdf will understand font metrics so it will be
>       possible to do layout.

I very much doubt you can do sensible layout in Lisp.  shr.el tries,
but the result is slow and incomplete -- and it does that with text
displayed by Emacs itself, whereas you are talking about something
more ambitious.

If you want to do layout for PDF, I think one way forward would be to
implement a pdfterm.c "terminal" for Emacs, which produces PDF like
the existing *term.c backends do for supported display types.

>    c) There are functions frame-width and frame-height.  Are there also
>       functions something like buffer-width and buffer-height and or a
>       way to compute x and y position relative to frame origin, which
>       would allow me to position images exactly in the buffer similar to
>       what w3m browser does?

Yes, there are, but they need a window to compute these metrics.
Without a live window, "buffer width" is meaningless, because buffer
text doesn't define the fonts (more generally, the typefaces) used for
displaying the text.  Only a window in which a buffer is displayed
provides enough typeface information to do these calculations.

> 4) Emacs is missing some kind of canvas, where things could be drawn and
>    which would handle pixel precise input.
> 
>    For example, I would like to browse OpenStreetMap in Emacs.  I wrote
>    a console based OSM browser osmq
>    <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
>    <https://osmq.eu/>.  I would prefer an Emacs based map browser.
>    However, I have not figured out how to lay out images in Emacs in a
>    grid and how to detect which image was clicked.  A bonus would be,
>    where exactly was clicked.  Any ideas what should I look into?

Emacs supports "hot spots" on images for this: a click on an image
returns information about pixel-resolution offset of the click from
the image origin.  I think that's what you want, although I'm not 100%
sure.

We also support displaying slices of images, in case that helps to
produce a smarter layout of images.

> It seems to me that these points are precondition for a WYSIWYG document
> editor feature in Emacs.

FWIW, I don't think these points are necessarily preconditions for
WYSIWYG features.  They are important and useful features, but a
WYSIWYG document editor should IMO start with something whose
beginning we have in enriched-mode.  That mode currently lacks the
ability of laying out text in variable-pitch typefaces, which I think
is the first extension of enriched-mode that should be worked on.
Followed by page layout and page breaks, intelligent sectioning
commands, etc. etc.  And yes, printing is also important, whether it
is done by producing PDF or PostScript or any other intermediate
format.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Tomas Hlavaty <tom@logand.com>
>> Date: Fri, 05 Jun 2020 23:54:08 +0200
>> Cc: emacs-devel@gnu.org
>> 
>>       It seems that there is some code in Emacs dealing with unicode
>>       fonts in order to generate postscript files.  Any pointers where
>>       to start with this?
>
> I think you should provide more details about the particular problem
> you are trying to solve here, because I don't think I understand it.
> Emacs generally knows only about fonts it uses for its own display,
> and it needs to load the font before it can provide information about
> it.  Whereas you seem to be talking about fonts to be used in the PDF
> file, not in Emacs display.

I poked around a bit and it seems that what I did in emacs-pdf
(pdf-buffer function) is similar to what ps-print-buffer function does
in ps-print and ps-mule with ps-multibyte-buffer set to nil.

Now I want something like ps-multibyte-buffer, e.g. pdf-multibyte-buffer
so that I can use non-ASCII characters in the generated PDF.  So I
probably want to implement something similar to ps-multibyte-buffer
cases of non-latin-printer, bdf-font and/or bdf-font-except-latin.

There seem to be ps-bdf so maybe I have to look, if I can reuse
something when generating PDF.

>>    b) After that, emacs-pdf will understand font metrics so it will be
>>       possible to do layout.
>
> I very much doubt you can do sensible layout in Lisp.  shr.el tries,
> but the result is slow and incomplete -- and it does that with text
> displayed by Emacs itself, whereas you are talking about something
> more ambitious.

For printing, this might not be an issue.

> If you want to do layout for PDF, I think one way forward would be to
> implement a pdfterm.c "terminal" for Emacs, which produces PDF like
> the existing *term.c backends do for supported display types.

I'll have a look, thanks.

>>    c) There are functions frame-width and frame-height.  Are there also
>>       functions something like buffer-width and buffer-height and or a
>>       way to compute x and y position relative to frame origin, which
>>       would allow me to position images exactly in the buffer similar to
>>       what w3m browser does?
>
> Yes, there are, but they need a window to compute these metrics.
> Without a live window, "buffer width" is meaningless, because buffer
> text doesn't define the fonts (more generally, the typefaces) used for
> displaying the text.  Only a window in which a buffer is displayed
> provides enough typeface information to do these calculations.

I see.

There is frame-position but no window-position.  Is there a way to get
window position in a frame?

>> 4) Emacs is missing some kind of canvas, where things could be drawn and
>>    which would handle pixel precise input.
>> 
>>    For example, I would like to browse OpenStreetMap in Emacs.  I wrote
>>    a console based OSM browser osmq
>>    <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
>>    <https://osmq.eu/>.  I would prefer an Emacs based map browser.
>>    However, I have not figured out how to lay out images in Emacs in a
>>    grid and how to detect which image was clicked.  A bonus would be,
>>    where exactly was clicked.  Any ideas what should I look into?
>
> Emacs supports "hot spots" on images for this: a click on an image
> returns information about pixel-resolution offset of the click from
> the image origin.  I think that's what you want, although I'm not 100%
> sure.

Yes.  Is there an example how to start with this?

> We also support displaying slices of images, in case that helps to
> produce a smarter layout of images.

Great.  Is there an example?

>> It seems to me that these points are precondition for a WYSIWYG document
>> editor feature in Emacs.
>
> FWIW, I don't think these points are necessarily preconditions for
> WYSIWYG features.  They are important and useful features, but a
> WYSIWYG document editor should IMO start with something whose
> beginning we have in enriched-mode.  That mode currently lacks the
> ability of laying out text in variable-pitch typefaces, which I think
> is the first extension of enriched-mode that should be worked on.
> Followed by page layout and page breaks, intelligent sectioning
> commands, etc. etc.  And yes, printing is also important, whether it
> is done by producing PDF or PostScript or any other intermediate
> format.

Interesting.  Maybe the pdfterm.c you suggested is kind of canvas I
wrote about.  When there is all that complexity with pixel perfect
drawing and layout, it would be shame to limit it to enriched mode.  But
it is still too early to make decisions in this direction.

Thank you for your help and quick and helpful answers!

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 07 Jun 2020 10:03:35 +0200
> 
> I poked around a bit and it seems that what I did in emacs-pdf
> (pdf-buffer function) is similar to what ps-print-buffer function does
> in ps-print and ps-mule with ps-multibyte-buffer set to nil.

BDF fonts were OK when ps-mule.el and ps-bdf.el were developed, but
nowadays I think you will find that many users will object to using
bitmapped fonts in printed matter.  (There were plans to develop
ps-type1.el, but I don't think they materialized.)  Caveat emptor.

> There is frame-position but no window-position.  Is there a way to get
> window position in a frame?

Is window-edges what you want?

> >>    For example, I would like to browse OpenStreetMap in Emacs.  I wrote
> >>    a console based OSM browser osmq
> >>    <https://logand.com/sw/osmq/log.html> and web-based OSM browser at
> >>    <https://osmq.eu/>.  I would prefer an Emacs based map browser.
> >>    However, I have not figured out how to lay out images in Emacs in a
> >>    grid and how to detect which image was clicked.  A bonus would be,
> >>    where exactly was clicked.  Any ideas what should I look into?
> >
> > Emacs supports "hot spots" on images for this: a click on an image
> > returns information about pixel-resolution offset of the click from
> > the image origin.  I think that's what you want, although I'm not 100%
> > sure.
> 
> Yes.  Is there an example how to start with this?

I suggest to read "Click Events" and "Accessing Mouse" in the ELisp
manual, I think the description there is clear enough to let you write
code even without examples.

> > We also support displaying slices of images, in case that helps to
> > produce a smarter layout of images.
> 
> Great.  Is there an example?

Likewise here: I suggest to read "Showing Images", where this is
described.

Re: "Why is emacs so square?"

[Tomas Hlavaty]

Eli Zaretskii <eliz@gnu.org> writes:
>> There is frame-position but no window-position.  Is there a way to get
>> window position in a frame?
>
> Is window-edges what you want?

Yes, window-edges is what I was looking for, thanks.  Now I can draw
images in console exactly where they should be.

However, there seem to be problem with get-buffer-window function:

get-buffer-window returns one buffer or nil.  This seems wrong because a
buffer can be visible on many windows.

Is there a function (or trick) which returns all windows, where a
specified buffer is visible?

RE: "Why is emacs so square?"

[Drew Adams]

> get-buffer-window returns one buffer or nil.  This seems wrong because a
> buffer can be visible on many windows.

(Typo - it returns one window, not one buffer.)

> Is there a function (or trick) which returns all windows, where a
> specified buffer is visible?

`C-h f get-buffer-window-list'

(get-buffer-window-list nil nil 'visible)

RE: "Why is emacs so square?"

[Tomas Hlavaty]

Drew Adams <drew.adams@oracle.com> writes:
>> get-buffer-window returns one buffer or nil.  This seems wrong because a
>> buffer can be visible on many windows.
>
> (Typo - it returns one window, not one buffer.)

yes, sorry about that

>> Is there a function (or trick) which returns all windows, where a
>> specified buffer is visible?
>
> `C-h f get-buffer-window-list'
>
> (get-buffer-window-list nil nil 'visible)

great, thank you!

Re: "Why is emacs so square?"

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

We certainly should have a pdf-print-buffer.
One way would be to call ps-print-buffer
and then run ps2pdf.

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

Re: "Why is emacs so square?"

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

  > > That statement may be correct, but you've changed the topic.

  > Did I?

  > The topic was Emacs's popularity, AFAICT.

Yes.  I want Emacs to become once again popular for editing text for
publication, as it was before.

More than that, I want to use it myself that way.

  > As a word processor, it's a lot less capable, and adding the two 
  > features you mentioned above won't bring us much closer to that goal, 

A long journey has to be achieved step by step.  Since 1990 I have
planned to extend Emacs to do word processing.  If that doesn't
interest you, you don't have to help, but please don't get in the way.

  > And there are existing Free programs 
  > that do this better already (like LibreOffice Writer).

I use LibreOffice.  It works, but I very much miss the 
fundamental capabilities of Emacs.

I want to do word processing in Emacs and program commands in Emacs Lisp.

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

Re: "Why is emacs so square?"

[Joost Kremers]

On Tue, Apr 21 2020, Richard Stallman wrote:
> I use LibreOffice.  It works, but I very much miss the 
> fundamental capabilities of Emacs.
>
> I want to do word processing in Emacs and program commands in 
> Emacs Lisp.

Lots of people are writing books and articles in Emacs using Org 
mode, which is as close to a full-blown office suite (word 
processor, PIM, spread sheet, presentation editor) as any text 
editor will get. If you want to do word processing in Emacs, you 
should check it out and see where it can be improved/extended to 
get to where you want Emacs to go.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

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

I found it impossible to learn what Org mode does.  Its introduction
taught how to do outline editing.  It made sense, but outline editing
useful for me, so I stopped reading.  I did not want to study use of a
mode for outline editing.

When you tell me that Emacs has important facilities -- doing jobs
very different from outline editing -- that I don't know about because
they have been integrated as "part of Org mode", my conclusion is that
we should have integrated them differently.  Those other facilities
should not be treated as "part of Org mode".  They should be separate
facilities, each one documented separately, and usable by itself.

I would like to see those facilities separated from Org mode and made
into separate first-class subsystems.  Then they can be documented in
the Emacs manual.

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

Re: "Why is emacs so square?"

[Nicolas Goaziou]

Hello,

Richard Stallman <rms@gnu.org> writes:

> When you tell me that Emacs has important facilities -- doing jobs
> very different from outline editing -- that I don't know about because
> they have been integrated as "part of Org mode", my conclusion is that
> we should have integrated them differently.  Those other facilities
> should not be treated as "part of Org mode".  They should be separate
> facilities, each one documented separately, and usable by itself.
>
> I would like to see those facilities separated from Org mode and made
> into separate first-class subsystems.  Then they can be documented in
> the Emacs manual.

There may be a misconception about what Org really is. It is unfortunate
if its documentation lets one think the mode is about outline editing.

  Org is both a lightweight markup language, and a major mode to edit
  it. Versatile, it is useful for keeping notes, maintaining TODO lists,
  and project planning. Powerful, it may be used as a complete authoring
  system, with support for literate programming and reproducible
  research.

Outline editing is but the design choice that was made for the major
mode to edit documents with Org syntax. To put it differently, the
common factor between the "other facilities" you mention, whatever they
are, is not the outliner part, but the markup language behind it.

As a consequence, it probably makes little sense to separate such
"facilities"---the term would need to be properly defined in the current
context, tho---, because each of them implies full support for the whole
Org syntax.

As a side node, there are attempts to proceed the other way. For example
OrgTbl minor mode, included in Org for historical reasons, edits---a
subset of---Org tables in other major modes. Likewise, Orgalist, found
in GNU ELPA, ports---a subset of---Org lists to other major modes. None
of them equates its native counterpart for the reasons explained above.

Conversely, I'm thinking out loud here, there is one external facility
that I would like to see integrated into Emacs proper, so major modes,
such as Org, could use it. It is Citeproc.el, a library for rendering
citations and bibliographies in styles described in the Citation Style
Language (CSL).

Regards,

-- 
Nicolas Goaziou

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Date: Wed, 22 Apr 2020 11:12:59 +0200
> Cc: Joost Kremers <joostkremers@fastmail.fm>, emacs-devel@gnu.org
> 
> > When you tell me that Emacs has important facilities -- doing jobs
> > very different from outline editing -- that I don't know about because
> > they have been integrated as "part of Org mode", my conclusion is that
> > we should have integrated them differently.  Those other facilities
> > should not be treated as "part of Org mode".  They should be separate
> > facilities, each one documented separately, and usable by itself.
> >
> > I would like to see those facilities separated from Org mode and made
> > into separate first-class subsystems.  Then they can be documented in
> > the Emacs manual.
> 
> There may be a misconception about what Org really is. It is unfortunate
> if its documentation lets one think the mode is about outline editing.
> 
>   Org is both a lightweight markup language, and a major mode to edit
>   it. Versatile, it is useful for keeping notes, maintaining TODO lists,
>   and project planning. Powerful, it may be used as a complete authoring
>   system, with support for literate programming and reproducible
>   research.
> 
> Outline editing is but the design choice that was made for the major
> mode to edit documents with Org syntax. To put it differently, the
> common factor between the "other facilities" you mention, whatever they
> are, is not the outliner part, but the markup language behind it.

IMNSHO, the Org manual "needs work"™.  Its current form shows the long
history of the package, more than it shows what it is nowadays.  I
mean, consider this opening phrases in Introduction:

  Org is a mode for keeping notes, maintaining TODO lists, and project
  planning with a fast and effective plain-text markup language.  It also
  is an authoring system with unique support for literate programming and
  reproducible research.

     Org is implemented on top of Outline mode, which makes it possible to
  keep the content of large files well structured.  Visibility cycling and
  structure editing help to work with the tree.  Tables are easily created
  with a built-in table editor.  Plain text URL-like links connect to
  websites, emails, Usenet messages, BBDB entries, and any files related
  to the projects.

     Org develops organizational tasks around notes files that contain
  lists or information about projects as plain text.  Project planning and
  task management make use of metadata which is part of an outline node.
  Based on this data, specific entries can be extracted in queries and
  create dynamic _agenda views_ that also integrate the Emacs calendar and
  diary.  Org can be used to implement many different project planning
  schemes, such as David Allen’s GTD system.

Etc., etc.  I invite you to put yourself in the shows of a newcomer to
Org, and try to imagine how such a newcomer will be able to realize
that Org can be used as a word-processor...

So please don't be surprised that Richard thinks about this what he
thinks.

Now, suppose someone tells me that Org includes word-processing
capabilities, and I'm excited about that and want to learn how to do
that.  Here's the menu I'm presented with in the Top node:

  * Introduction::                 Getting started.
  * Document Structure::           A tree works like your brain.
  * Tables::                       Pure magic for quick formatting.
  * Hyperlinks::                   Notes in context.
  * TODO Items::                   Every tree branch can be a TODO item.
  * Tags::                         Tagging headlines and matching sets of tags.
  * Properties and Columns::       Storing information about an entry.
  * Dates and Times::              Making items useful for planning.
  * Refiling and Archiving::       Moving and copying information with ease.
  * Capture and Attachments::      Dealing with external data.
  * Agenda Views::                 Collecting information into views.
  * Markup for Rich Contents::     Compose beautiful documents.
  * Exporting::                    Sharing and publishing notes.
  * Publishing::                   Create a web site of linked Org files.
  * Working with Source Code::     Export, evaluate, and tangle code blocks.
  * Miscellaneous::                All the rest which did not fit elsewhere.
  * Hacking::                      How to hack your way around.
  * History and Acknowledgments::  How Org came into being.
  * GNU Free Documentation License:: The license for this documentation.
  * Main Index::                   An index of Org’s concepts and features.
  * Key Index::                    Key bindings and where they are described.
  * Command and Function Index::   Command names and some internal functions.
  * Variable Index::               Variables mentioned in the manual.

Hmm... which one of the chapters should I read?  I tried "Publishing"
first, but quickly realized that's not it.  Next, I tried "Exporting"
("Sharing and publishing notes.", right?) -- another false hit.
Finally, I thought maybe it's in "Markup for Rich Contents".  This
time I think I found what I was looking for, but look at that
chapter's menu:

  * Paragraphs::                   The basic unit of text.
  * Emphasis and Monospace::      Bold, italic, etc.
  * Subscripts and Superscripts:: Simple syntax for raising/lowering text.
  * Special Symbols::              Greek letters and other symbols.
  * Embedded LaTeX::               LaTeX can be freely used inside Org documents.
  * Literal Examples::             Source code examples with special formatting.
  * Images::                       Display an image.
  * Captions::                     Describe tables, images...
  * Horizontal Rules::             Make a line.
  * Creating Footnotes::           Edit and read footnotes.

This sounds like a more-or-less random collection of related tidbits,
not an explanation of how to use Org as a word-processor.  And as soon
as I go to the first section, "Paragraphs", I'm almost immediately
lost:

  Paragraphs are separated by at least one empty line.  If you need to
  enforce a line break within a paragraph, use ‘\\’ at the end of a line.

     To preserve the line breaks, indentation and blank lines in a region,
  but otherwise use normal formatting, you can use this construct, which
  can also be used to format poetry.

       #+BEGIN_VERSE
	Great clouds overhead
	Tiny black birds rise and fall
	Snow covers Emacs

	   ---AlexSchroeder
       #+END_VERSE

What are those "#+BEGIN_VERSE" and "#+END_VERSE" markers?  Do I type
them verbatim in the text of a document?  There's no answer.  (Of
course, yours truly is somewhat familiar with Org, so _I_ know the
answer.  But a newbie won't.)

This is not what a chapter about using a word processor should look
like.  It should begin with an introduction to word-processing with
Org, an overview of what's possible and what isn't; it should go on to
explaining how to start a document, how to write a heading and a
sub-heading, how to insert references, links, footnotes, and other
objects; it should then explain how to produce a TOC and an index, and
finally point me to another chapter that explains how to export my
document in a variety of formats.

A good example of how such documentation should be structured is at
the beginning of the Texinfo manual, which also describes a system for
writing documents.  Look at the first dozen of chapters there for
inspiration.

> As a consequence, it probably makes little sense to separate such
> "facilities"---the term would need to be properly defined in the current
> context, tho---, because each of them implies full support for the whole
> Org syntax.

Maybe you took the "separate" part to mean that the _code_ should be
separated or subdivided.  I'm not sure Richard meant that, but even if
he did, what I would like to see is a "separation" on the
documentation level.  Let a user who only wants to write documents
with Org be able to learn that without reading 50% of the Org manual,
in order to understand "the whole Org syntax".  Allow a user who is
only interested in GTD to be able to do just that by learning the
necessary Org commands and procedures, and little else.  Etc. etc. --
try to "separate" what Org is capable of into several large classes of
jobs, and make sure each of these classes is documented clearly and
logically, as if it were a separate manual (and maybe it really should
be a separate manual, I don't know).

I hope I explained at least what is my view of how Org should evolve
(in addition to the routine development that adds new features) -- it
should try to present a less monolith-like appearance towards new
users, and allow them to master just a part of its capabilities, the
part that they are interested in.

HTH and TIA

Re: "Why is emacs so square?"

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

I have learned a lot more about Org mode from your message
than I was able ever to learn before.  Thank you.

  > This is not what a chapter about using a word processor should look
  > like.  It should begin with an introduction to word-processing with
  > Org, an overview of what's possible and what isn't; it should go on to
  > explaining how to start a document, how to write a heading and a
  > sub-heading, how to insert references, links, footnotes, and other
  > objects; it should then explain how to produce a TOC and an index, and
  > finally point me to another chapter that explains how to export my
  > document in a variety of formats.

That plan for a manual for the word-processing feature makes sense.

It appears that what people call "Org mode" is a collection of diverse
features, and what they have in common is use of a certain format of
the text.  Is that right?

I have to question the practice of treating these diverse features
conceptually as a single mode.  Although I still don't know what those
features are, if one of them is a word processor and the others are not,
they are too different to make sense conceptually that way.

It would make more sense to call them various different modes.  That
they all use a certain way of formatting the text may not be important
to mention.  If it is useful to have a name for that, I suggest the
name "Org format".  Each of these modes could say it uses "Org
format", or perhaps a variation of that.

  > > As a consequence, it probably makes little sense to separate such
  > > "facilities"---the term would need to be properly defined in the current
  > > context, tho---, because each of them implies full support for the whole
  > > Org syntax.

Maybe that is how things are now, but is there a reason why things
SHOULD be done this way?  Does each of these features need to support
"the whole Org syntax"?

It could be that the simple way of implementing them is by sharing code
that implements "the whole Org syntax".  If so, I won't argue against
sharing that code.  But it may not be useful to TALK about the fact
that each one implements "the whole Org syntax".  And it is possilble
that it is better to share only part of that code, not all.

In other words, if we don't let the concept of "Org mode" shape our thinking,
we might thing of these features differently.

  > I hope I explained at least what is my view of how Org should evolve
  > (in addition to the routine development that adds new features) -- it
  > should try to present a less monolith-like appearance towards new
  > users, and allow them to master just a part of its capabilities, the
  > part that they are interested in.

Hear, hear!

  > HTH and TIA

Hold Turnip Head and Turn It Around?  ;-}


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

Re: "Why is emacs so square?"

[Joost Kremers]

On Thu, Apr 23 2020, Richard Stallman wrote:
> It appears that what people call "Org mode" is a collection of 
> diverse
> features, and what they have in common is use of a certain 
> format of
> the text.  Is that right?

That sounds just about right, yes.

> I have to question the practice of treating these diverse 
> features
> conceptually as a single mode.  Although I still don't know what 
> those
> features are, if one of them is a word processor and the others 
> are not,
> they are too different to make sense conceptually that way.

The practice has probably arisen historically, but IMHO it still 
makes sense to do so now, because probably Org's biggest strength 
is that the various features are tightly integrated. That doesn't 
mean you couldn't use Org for just one of its features, you 
definitely could, but the beauty of the system is that the 
different features aren't strictly separated.

For example, Org can be used as an agenda, to keep track of your 
appointments, daily schedule, etc., much like Google Calendar and 
other such offerings. At the same time, you can use Org to write 
your papers.

Now, you would normally keep your appointments in one file, say 
=agenda.org=, and the paper you're working on in another file, say 
=paper.org=. So far, so uninteresting. But with Org you can put 
TODO notes in =paper.org=, add deadlines, date and time stamps, 
etc., anything Org supports. Then, when you display your agenda 
(i.e., run a function that takes the contents of, in this example, 
=agenda.org=, and creates a nice overview of it in an agenda-like 
fashion), you can have the TODO items, deadlines etc. from 
=paper.org= included in this overview automatically. Try that with 
Google Calendar.

This is just one example, but it illustrates the whole point of 
Org: the system has many different features, and they all work 
together.

> It would make more sense to call them various different modes. 
> That
> they all use a certain way of formatting the text may not be 
> important
> to mention.

Actually, it's crucial to mention that. You might say it's Org's 
raison d'être. It's what makes integrating all of Org's functions 
so tightly possible.

> In other words, if we don't let the concept of "Org mode" shape 
> our thinking,
> we might thing of these features differently.

I think it would certainly help newbies getting started with Org 
to document its features separately. Eli's suggestions for 
restructuring the Org manual sound very good. I had a difficult 
time getting started with Org myself, and I can relate very well 
to the impressions that you and Eli describe.

But at the same time it should be made clear from the outset that 
Org's strength lies in its integration. I mean, I could use 
Markdown with Pandoc to write my papers, *cough* Google Calendar 
*cough* to keep track of my appointments, Jupyter for keeping 
programming notebooks and *cough* Evernote *cough* to keep notes, 
but there would be no way to link all of that. With Org, there is.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Thu, 23 Apr 2020 10:41:05 +0200
> 
> > It would make more sense to call them various different modes.
> > That they all use a certain way of formatting the text may not be
> > important to mention.
> 
> Actually, it's crucial to mention that. You might say it's Org's 
> raison d'être. It's what makes integrating all of Org's functions 
> so tightly possible.

If features are well integrated and work together well, how is it
important to know that they do it because of a certain way of
formatting text?

> But at the same time it should be made clear from the outset that 
> Org's strength lies in its integration. I mean, I could use 
> Markdown with Pandoc to write my papers, *cough* Google Calendar 
> *cough* to keep track of my appointments, Jupyter for keeping 
> programming notebooks and *cough* Evernote *cough* to keep notes, 
> but there would be no way to link all of that. With Org, there is.

You are actually describe the strength of Emacs as an integrated
package whose parts work well with one another.  And yet we have
separate manuals for major parts: Gnus, Org, Eshell, etc. -- just look
inside doc/misc/.

IOW, I don't see a contradiction here.

Re: "Why is emacs so square?"

[Joost Kremers]

On Thu, Apr 23 2020, Eli Zaretskii wrote:
>> Actually, it's crucial to mention that. You might say it's 
>> Org's 
>> raison d'être. It's what makes integrating all of Org's 
>> functions 
>> so tightly possible.
>
> If features are well integrated and work together well, how is 
> it
> important to know that they do it because of a certain way of
> formatting text?

Because the user has to format that text. :-) Sure, there are 
helper functions for a lot of things, but as a user you do need to 
know the Org format.

>> But at the same time it should be made clear from the outset 
>> that 
>> Org's strength lies in its integration. I mean, I could use 
>> Markdown with Pandoc to write my papers, *cough* Google 
>> Calendar 
>> *cough* to keep track of my appointments, Jupyter for keeping 
>> programming notebooks and *cough* Evernote *cough* to keep 
>> notes, 
>> but there would be no way to link all of that. With Org, there 
>> is.
>
> You are actually describe the strength of Emacs as an integrated
> package whose parts work well with one another.  And yet we have
> separate manuals for major parts: Gnus, Org, Eshell, etc. -- 
> just look
> inside doc/misc/.

Yes, but it's a different level of integration. I need a decent 
working knowledge of Elisp to be able to integrate Gnus and 
Eshell. But I only need to know Org syntax in order to integrate 
my TODO list, task management and writing with my calendar. The 
point is, I need to know Org syntax anyway to do each single thing 
separately. Integrating them doesn't require a deeper level of 
knowledge than I already have.

> IOW, I don't see a contradiction here.

I'm not saying there's a contradiction. If that's how I came 
across, then I didn't make my point very well. Like I said, I 
think the Org documentation would benefit greatly if your 
suggestions were implemented. It's just that the fact that Org's 
different parts are tightly integrated should not be tucked away 
in some "Advanced Use" section of the manual.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Fri, 24 Apr 2020 08:36:49 +0200
> 
> > You are actually describe the strength of Emacs as an integrated
> > package whose parts work well with one another.  And yet we have
> > separate manuals for major parts: Gnus, Org, Eshell, etc. -- 
> > just look
> > inside doc/misc/.
> 
> Yes, but it's a different level of integration. I need a decent 
> working knowledge of Elisp to be able to integrate Gnus and 
> Eshell. But I only need to know Org syntax in order to integrate 
> my TODO list, task management and writing with my calendar. The 
> point is, I need to know Org syntax anyway to do each single thing 
> separately. Integrating them doesn't require a deeper level of 
> knowledge than I already have.

Unless I misunderstand what you mean by "Org syntax", I don't think
users who want to create documents with Org should be required to know
that syntax.  Instead, there should be commands to help them produce
correctly formatted snippets.  Compare that with Texinfo commands
which produce the various syntactic elements of the language.

Re: "Why is emacs so square?"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Unless I misunderstand what you mean by "Org syntax", I don't think
> users who want to create documents with Org should be required to know
> that syntax.  Instead, there should be commands to help them produce
> correctly formatted snippets.

I'm not sure what you mean here.  AFAICT, there are already several
such commands.

- To insert a new headline, type 'M-RET'.
- To insert a source block, type '< s TAB'.
- To insert org export headers, type ''C-c C-e #'.
- To schedule a headline for later, type 'C-c C-s'.
- To insert a link, type 'C-c C-l'.
- etc.

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 24 Apr 2020 12:28:01 +0200
> Cc: Joost Kremers <joostkremers@fastmail.fm>, Emacs developers <emacs-devel@gnu.org>
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Unless I misunderstand what you mean by "Org syntax", I don't think
> > users who want to create documents with Org should be required to know
> > that syntax.  Instead, there should be commands to help them produce
> > correctly formatted snippets.
> 
> I'm not sure what you mean here.  AFAICT, there are already several
> such commands.
> 
> - To insert a new headline, type 'M-RET'.
> - To insert a source block, type '< s TAB'.
> - To insert org export headers, type ''C-c C-e #'.
> - To schedule a headline for later, type 'C-c C-s'.
> - To insert a link, type 'C-c C-l'.
> - etc.

Then it seems like I was right: there's no need for users who want to
produce documents with Org to be proficient in the Org syntax.  Right?

Re: "Why is emacs so square?"

[Steinar Bang]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Then it seems like I was right: there's no need for users who want to
> produce documents with Org to be proficient in the Org syntax.  Right?

Yes it's probably sufficient to know the commands and let the text flow
the way it likes.

(I.e. pretty much the way AUCTeX works. I know people back in the 80-ies
and 90-ies who needed to write LaTeX and became emacs users solely
becaause of AUCTeX)

(in both cases, understanding the syntax helps both in understanding
what goes on, and in navigating)

Re: "Why is emacs so square?"

[Joost Kremers]

On Fri, Apr 24 2020, Eli Zaretskii wrote:
> Unless I misunderstand what you mean by "Org syntax", I don't 
> think
> users who want to create documents with Org should be required 
> to know
> that syntax.  Instead, there should be commands to help them 
> produce
> correctly formatted snippets.  Compare that with Texinfo 
> commands
> which produce the various syntactic elements of the language.

Yes, there are usually helper functions to do just that, though 
for some things, it's easier to just type the markup directly. 
(`*bold*` is IMHO quicker than `C-c C-x C-f * bold C-f`.) But once 
I know how to create a heading in a text document I can use the 
same command to create a heading in a notes file or an agenda 
file.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Fri, 24 Apr 2020 12:36:43 +0200
> 
> 
> On Fri, Apr 24 2020, Eli Zaretskii wrote:
> > Unless I misunderstand what you mean by "Org syntax", I don't 
> > think
> > users who want to create documents with Org should be required 
> > to know
> > that syntax.  Instead, there should be commands to help them 
> > produce
> > correctly formatted snippets.  Compare that with Texinfo 
> > commands
> > which produce the various syntactic elements of the language.
> 
> Yes, there are usually helper functions to do just that, though for
> some things, it's easier to just type the markup directly.
> (`*bold*` is IMHO quicker than `C-c C-x C-f * bold C-f`.) But once I
> know how to create a heading in a text document I can use the same
> command to create a heading in a notes file or an agenda file.

Command efficiency aside, if such commands exists, then why would the
user need to know the Org syntax which they produce?

Re: "Why is emacs so square?"

[Ricardo Wurmus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Date: Fri, 24 Apr 2020 08:36:49 +0200
[…]
>> The 
>> point is, I need to know Org syntax anyway to do each single thing 
>> separately. Integrating them doesn't require a deeper level of 
>> knowledge than I already have.
>
> Unless I misunderstand what you mean by "Org syntax", I don't think
> users who want to create documents with Org should be required to know
> that syntax.  Instead, there should be commands to help them produce
> correctly formatted snippets.  Compare that with Texinfo commands
> which produce the various syntactic elements of the language.

I would like to not have to bother with Org syntax at all, but after
using the commands that produce it I see that syntax.  It can be very
confusing to see an unfamiliar syntax after issuing a command — what
parts of it may I edit?  When I accidentally remove parts of it, how can
I restore the full syntax?

Two things would help here, in my opinion:

* hide the textual representation.

  My Org mode configuration replaces “*”, “**”, “***”, “****” with
  “bullets” like "◉", "○", "◇", and "◇".  I can produce them either by
  tying “*” (if I know that syntax) or by using M-RET and S-right.  Org
  mode hides the syntax for URLs when [[…][…]] is used and displays just
  an underlined and clickable URL.

  For source code blocks I replace “#+begin_src” and “#+end_src” with
  markers like ✎ and □ and set the block visually apart by customizing
  the faces. (See https://pank.eu/blog/pretty-babel-src-blocks.html)

* delete the whole construct instead of deleting characters.  Currently,
  it is easy to end up with invalid syntax by deleting parts of the
  markup text.  Deleting the trailing “c” of “#+end_src” at the end of a
  source code block, for example, breaks that code block but leaves the
  “#+begin_src” and now incomplete “#+end_sr” where they are.  I need to
  know that I have to append a “c” at the end to restore the code
  block.  There is no command I can run to “repair” this code block.
  Maybe it would be good to remove the whole textual markup at once,
  leaving only the user-provided text that was marked up.

By making it impossible or very unlikely to produce incorrect markup and
by hiding the markup syntax itself the user wouldn’t have to learn it
and also wouldn’t be exposed to it accidentally.

At that point the syntax itself becomes secondary; this would then be
similar to how enriched-mode works.

-- 
Ricardo

Re: "Why is emacs so square?"

[Arthur Miller]

Ricardo Wurmus <rekado@elephly.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Joost Kremers <joostkremers@fastmail.fm>
>>> Date: Fri, 24 Apr 2020 08:36:49 +0200
> […]
>>> The 
>>> point is, I need to know Org syntax anyway to do each single thing 
>>> separately. Integrating them doesn't require a deeper level of 
>>> knowledge than I already have.
>>
>> Unless I misunderstand what you mean by "Org syntax", I don't think
>> users who want to create documents with Org should be required to know
>> that syntax.  Instead, there should be commands to help them produce
>> correctly formatted snippets.  Compare that with Texinfo commands
>> which produce the various syntactic elements of the language.
>
> I would like to not have to bother with Org syntax at all, but after
> using the commands that produce it I see that syntax.  It can be very
> confusing to see an unfamiliar syntax after issuing a command — what
> parts of it may I edit?  When I accidentally remove parts of it, how can
> I restore the full syntax?
>
> Two things would help here, in my opinion:
>
> * hide the textual representation.
>
>   My Org mode configuration replaces “*”, “**”, “***”, “****” with
>   “bullets” like "◉", "○", "◇", and "◇".  I can produce them either by
>   tying “*” (if I know that syntax) or by using M-RET and S-right.  Org
>   mode hides the syntax for URLs when [[…][…]] is used and displays just
>   an underlined and clickable URL.
>
>   For source code blocks I replace “#+begin_src” and “#+end_src” with
>   markers like ✎ and □ and set the block visually apart by customizing
>   the faces. (See https://pank.eu/blog/pretty-babel-src-blocks.html)
>
> * delete the whole construct instead of deleting characters.  Currently,
>   it is easy to end up with invalid syntax by deleting parts of the
>   markup text.  Deleting the trailing “c” of “#+end_src” at the end of a
>   source code block, for example, breaks that code block but leaves the
>   “#+begin_src” and now incomplete “#+end_sr” where they are.  I need to
>   know that I have to append a “c” at the end to restore the code
>   block.  There is no command I can run to “repair” this code block.
>   Maybe it would be good to remove the whole textual markup at once,
>   leaving only the user-provided text that was marked up.
>
> By making it impossible or very unlikely to produce incorrect markup and
> by hiding the markup syntax itself the user wouldn’t have to learn it
> and also wouldn’t be exposed to it accidentally.
>
> At that point the syntax itself becomes secondary; this would then be
> similar to how enriched-mode works.

When I accidentally delete a part of markup, usually '[' or ']' in a
link, it is immidiately reflected visually in the buffer so I just undo
to "restore". For me it is just C-S--.

But I do agree it would be usefull to make some markup "atomic", like
for example "#+BEGIN_SRC", "#+END_SRC". But for some other markup it
might be difficult. For example leading '*': sometimes it might be a
misstake, but sometimes it might be intentionally, for example to change
hte heading from say *** to **. 

Re: "Why is emacs so square?"

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

  > Org's biggest strength 
  > is that the various features are tightly integrated.

You may see that as an advantage, but I consider it a drawback.  The
"tight integration" of these different features is an obstacle to
learning to use one of them, or even finding out about one of them.

*We need to make them separate.*

Separate and integrated are not opposites.
It is possible for several features to be integrated,
in the sense that they work together _when you want that_,
and also separate, in the sense that we describe each one separately
and you can learn about one without paying the slightest attention
to the others.

							 That doesn't 
  > mean you couldn't use Org for just one of its features, you 
  > definitely could, but the beauty of the system is that the 
  > different features aren't strictly separated.

I would say that is the complexity and obscurity of the system.

I think we can make them clearly separate, for purposes
of documenting them, without reducing the ability to integrate them
for users who use more than one.

  > =paper.org=. So far, so uninteresting. But with Org you can put 
  > TODO notes in =paper.org=, add deadlines, date and time stamps, 
  > etc., anything Org supports. Then, when you display your agenda 
  > (i.e., run a function that takes the contents of, in this example, 
  > =agenda.org=, and creates a nice overview of it in an agenda-like 
  > fashion), you can have the TODO items, deadlines etc. from 

I can see that that integration is useful -- but _the fact that it
applies only to "parts of Org mode"_ makes it also a a limitation.
It is a drawback that _only_ the modes that are "part of Org mode" can
integrate with these features -- and the rest of Emacs cannot do so.

Instead of dividing Emacs facilities and modes into the "Org
first-class modes" and the "Org second-class modes", we should make
all modes equally able to integrate in these ways.

  > > It would make more sense to call them various different modes. 
  > > That
  > > they all use a certain way of formatting the text may not be 
  > > important
  > > to mention.

  > Actually, it's crucial to mention that.

People who want to use a specific one of these facilities don't need
to know that.  It is useful for those users who want to use more
than one of these facilities together -- but that should be
an advanced topic.

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

Re: "Why is emacs so square?"

[Joost Kremers]

On Fri, Apr 24 2020, 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. ]]]
>
>   > Org's biggest strength 
>   > is that the various features are tightly integrated.
>
> You may see that as an advantage, but I consider it a drawback. 
> The
> "tight integration" of these different features is an obstacle 
> to
> learning to use one of them, or even finding out about one of 
> them.

No, it really isn't. It's just the way the current documentation 
is set up that makes this difficult. (I know, I agree, I've been 
there.)

> Separate and integrated are not opposites.
> It is possible for several features to be integrated,
> in the sense that they work together _when you want that_,
> and also separate, in the sense that we describe each one 
> separately
> and you can learn about one without paying the slightest 
> attention
> to the others.

Again, that's all about documentation.

> I can see that that integration is useful -- but _the fact that 
> it
> applies only to "parts of Org mode"_ makes it also a a 
> limitation.
> It is a drawback that _only_ the modes that are "part of Org 
> mode" can
> integrate with these features -- and the rest of Emacs cannot do 
> so.
> 
> Instead of dividing Emacs facilities and modes into the "Org
> first-class modes" and the "Org second-class modes", we should 
> make
> all modes equally able to integrate in these ways.

That sounds good in theory, but I'm really not sure what that 
would mean in practice. (I'm not entirely sure that you do either. 
;-) The reason Org's facilities can be so tightly integrated is 
because they all use the same Org syntax. Org files are just plain 
text files with a well-defined markup, after all.

As for integrating with the rest of Emacs, any part of Emacs is 
free to make use of this syntax as well, Org in fact provides 
libraries to make this easier. For example, I maintain a package 
for managing .bib files. It integrates with Org in that the user 
can add notes to bib entries, which are kept in Org files, and the 
user can maintain a reading list, also as an Org file, which then 
integrates with the user's TODO list and calendar, if s/he so 
wishes. I started this package long before I ever heard of Org 
mode, but it was easy to add this functionality once I realised it 
would be useful to do so.

So I believe the kind of integration you talk about is already 
possible, you just need to write the Elisp code to do it. In that 
way it doesn't differ from all the other facilities that Emacs 
provides: if I want to integrate Gnus and Eshell (whatever that 
would mean), I need to write Elisp code.

This of course contrasts with the integration of the various 
facilities that Org provides, because that only requires knowledge 
of Org's syntax. But I believe that's OK and fully expected: the 
things Org can do are closely related and many people *need* them 
to integrate well with each other. So integrating them should be 
easy.

On the other hand, what Gnus does has little to do with what 
Eshell does and scenarios where it would be useful to integrate 
them are probably rare. So it's OK that that's not so easy to do, 
as long as it's not impossible.

> > > It would make more sense to call them various different 
> > > modes. That they all use a certain way of formatting the 
> > > text may not be important to mention.
>
>   > Actually, it's crucial to mention that.
>
> People who want to use a specific one of these facilities don't 
> need
> to know that.

Sure, but I don't think it's a big cognitive burden for them to 
know that. Pointing out this fact in a couple of crucial places 
wouldn't take more than a sentence or two, with a reference to a 
section where it's all explained in more detail.

>  It is useful for those users who want to use more
> than one of these facilities together -- but that should be
> an advanced topic.

No, it shouldn't be billed as an advanced topic, for two reasons. 
First, it really isn't advanced at all: like I said, you really 
only need to know Org syntax in order to integrate these 
facilities, and you need to know Org syntax anyway to be able to 
use just one facility. Second, the tight integration is one of the 
reasons people are attracted to Org mode in the first place, so 
it's likely something people will look for in a manual early on.

Anyway, I think this subthread is slowly getting out of hand. :-) 
I don't believe our positions are as far apart as the discussion 
might suggest. I do agree with you and Eli that it would be very 
helpful if the Org manual were structured along the lines Eli 
suggested. I envisage an introductory section that clearly states 
the different use cases of Org and directs the reader to separate 
sections for each of them, which should all be written from the 
point of view of a new user, i.e., they shouldn't assume 
familiarity with any of the other use cases. At the same time, the 
introduction should mention Org's integrative nature and point the 
reader to relevant section(s), without labelling these as 
"advanced".

Whether and to what extent the Org code base should be modified, 
I'm not qualified to say, but given the limited resources, it 
isn't likely to happen anyway. Improving the documentation would 
be a much better investment of time.

-- 
Joost Kremers
Life has its moments

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 23 Apr 2020 22:37:48 -0400
> Cc: emacs-devel@gnu.org
> 
> Separate and integrated are not opposites.
> It is possible for several features to be integrated,
> in the sense that they work together _when you want that_,
> and also separate, in the sense that we describe each one separately
> and you can learn about one without paying the slightest attention
> to the others.

I think it's more correct to say that Org features are well
integrated, not that they are tightly-coupled in the sense that they
cannot work separately.  I did (and do) successfully use a couple of
Org features although I know and need very little of the rest.

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 12:59:06 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Richard Stallman <rms@gnu.org>
    >> Date: Thu, 23 Apr 2020 22:37:48 -0400
    >> Cc: emacs-devel@gnu.org
    >> 
    >> Separate and integrated are not opposites.
    >> It is possible for several features to be integrated,
    >> in the sense that they work together _when you want that_,
    >> and also separate, in the sense that we describe each one separately
    >> and you can learn about one without paying the slightest attention
    >> to the others.

    Eli> I think it's more correct to say that Org features are well
    Eli> integrated, not that they are tightly-coupled in the sense that they
    Eli> cannot work separately.  I did (and do) successfully use a couple of
    Eli> Org features although I know and need very little of the rest.

And that 'little' extends to the Org syntax: there is no need to know
all of it, or even a large part of it, since basic use just requires
something like:

    * Heading level one
      Text

    ** Heading level two
      Text

    * Another heading level one

    ** TODO do some stuff

Itʼs only when you start wanting to change org's default behaviour, or
generate a custom agenda, or schedule TODO items, or track task time
usage etc, that you need to learn more.

Robert

Re: "Why is emacs so square?"

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

  > I think it's more correct to say that Org features are well
  > integrated, not that they are tightly-coupled in the sense that they
  > cannot work separately.  I did (and do) successfully use a couple of
  > Org features although I know and need very little of the rest.

That is good news.

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: mail@nicolasgoaziou.fr, joostkremers@fastmail.fm,
> 	emacs-devel@gnu.org
> Date: Wed, 22 Apr 2020 22:36:55 -0400
> 
> It appears that what people call "Org mode" is a collection of diverse
> features, and what they have in common is use of a certain format of
> the text.  Is that right?

More or less, AFAIK.  The common features are more than just the
format, but the format is AFAIU the most important one.

>   > > As a consequence, it probably makes little sense to separate such
>   > > "facilities"---the term would need to be properly defined in the current
>   > > context, tho---, because each of them implies full support for the whole
>   > > Org syntax.
> 
> Maybe that is how things are now, but is there a reason why things
> SHOULD be done this way?  Does each of these features need to support
> "the whole Org syntax"?
> 
> It could be that the simple way of implementing them is by sharing code
> that implements "the whole Org syntax".  If so, I won't argue against
> sharing that code.  But it may not be useful to TALK about the fact
> that each one implements "the whole Org syntax".  And it is possilble
> that it is better to share only part of that code, not all.
> 
> In other words, if we don't let the concept of "Org mode" shape our thinking,
> we might thing of these features differently.

It may be too late to actually separate the various features,
especially since there doesn't seem to be anyone who'd want to do this
(very complex) job.  I think it would be a very useful step if the
documentations and the general classes of the Org features would
present to the users several disparate sets of capabilities, and would
allow users to learn and use only the set(s) they need.

>   > HTH and TIA
> 
> Hold Turnip Head and Turn It Around?  ;-}

Of course, what else?

Re: "Why is emacs so square?"

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

  > It may be too late to actually separate the various features,

Are you assuming that this means a lot of change in the code?
I have no idea whether it does.  Maybe most of the change needed
is in documentation, and a few little details to go with
the change in documentation.

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: joostkremers@fastmail.fm, mail@nicolasgoaziou.fr,
> 	emacs-devel@gnu.org
> Date: Thu, 23 Apr 2020 22:43:05 -0400
> 
>   > It may be too late to actually separate the various features,
> 
> Are you assuming that this means a lot of change in the code?

Yes, I think so.

> I have no idea whether it does.  Maybe most of the change needed
> is in documentation, and a few little details to go with
> the change in documentation.

I think we should try changing the documentation first, as that is a
Good Thing anyway.  When that is done, we could consider whether any
code changes are needed.  (I actually expect that to become evident
while the documentation is re-written in the directions I proposed:
whoever will do that job will discover that, for example, to be able
to produce a stand-alone document with Org, one would need features
that currently belong to some unrelated Org part -- which would mean
some code needs to be added or modified to make that feature
seamlessly available to document-writers.)

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 13:03:52 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> I have no idea whether it does.  Maybe most of the change needed
    >> is in documentation, and a few little details to go with
    >> the change in documentation.

    Eli> I think we should try changing the documentation first, as that is a
    Eli> Good Thing anyway.  When that is done, we could consider whether any
    Eli> code changes are needed.  (I actually expect that to become evident
    Eli> while the documentation is re-written in the directions I proposed:
    Eli> whoever will do that job will discover that, for example, to be able
    Eli> to produce a stand-alone document with Org, one would need features
    Eli> that currently belong to some unrelated Org part -- which would mean
    Eli> some code needs to be added or modified to make that feature
    Eli> seamlessly available to document-writers.)

That depends on what you mean by 'stand-alone'. The built-in Org mode
from 'emacs -Q' can export to at least html, latex, pdf and odt by
default, of which only latex and pdf require the installation of extra
external tools.

Thereʼs a texinfo backend as well that youʼd need to enable, which may
well require external tool support (Iʼve never used it).

Robert

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: rms@gnu.org,  joostkremers@fastmail.fm,  mail@nicolasgoaziou.fr,
>   emacs-devel@gnu.org
> Date: Fri, 24 Apr 2020 13:34:13 +0200
> 
>     Eli> I think we should try changing the documentation first, as that is a
>     Eli> Good Thing anyway.  When that is done, we could consider whether any
>     Eli> code changes are needed.  (I actually expect that to become evident
>     Eli> while the documentation is re-written in the directions I proposed:
>     Eli> whoever will do that job will discover that, for example, to be able
>     Eli> to produce a stand-alone document with Org, one would need features
>     Eli> that currently belong to some unrelated Org part -- which would mean
>     Eli> some code needs to be added or modified to make that feature
>     Eli> seamlessly available to document-writers.)
> 
> That depends on what you mean by 'stand-alone'. The built-in Org mode
> from 'emacs -Q' can export to at least html, latex, pdf and odt by
> default, of which only latex and pdf require the installation of extra
> external tools.

That's orthogonal.  By "stand-alone" I meant a document that doesn't
require support from any additional Org features, like TODO notes,
calendar appointments, etc.  Just a document that includes structured
text.

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 15:09:26 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: rms@gnu.org,  joostkremers@fastmail.fm,  mail@nicolasgoaziou.fr,
    >> emacs-devel@gnu.org
    >> Date: Fri, 24 Apr 2020 13:34:13 +0200
    >> 
    Eli> I think we should try changing the documentation first, as that is a
    Eli> Good Thing anyway.  When that is done, we could consider whether any
    Eli> code changes are needed.  (I actually expect that to become evident
    Eli> while the documentation is re-written in the directions I proposed:
    Eli> whoever will do that job will discover that, for example, to be able
    Eli> to produce a stand-alone document with Org, one would need features
    Eli> that currently belong to some unrelated Org part -- which would mean
    Eli> some code needs to be added or modified to make that feature
    Eli> seamlessly available to document-writers.)
    >> 
    >> That depends on what you mean by 'stand-alone'. The built-in Org mode
    >> from 'emacs -Q' can export to at least html, latex, pdf and odt by
    >> default, of which only latex and pdf require the installation of extra
    >> external tools.

    Eli> That's orthogonal.  By "stand-alone" I meant a document that doesn't
    Eli> require support from any additional Org features, like TODO notes,
    Eli> calendar appointments, etc.  Just a document that includes structured
    Eli> text.

None of those additional features are *required* for a document. All
you need to produce a document is org-markup, like

    This is some *bold* text, this is some /italic/ text, and this should
    be =monospace=

You donʼt even have to use headings if you donʼt want to. Or
footnotes. Or links. Or inline latex. But you *can* if you want
to.

Robert

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 24 Apr 2020 14:23:16 +0200
> Cc: joostkremers@fastmail.fm, rms@gnu.org, mail@nicolasgoaziou.fr,
>  emacs-devel@gnu.org
> 
>     Eli> That's orthogonal.  By "stand-alone" I meant a document that doesn't
>     Eli> require support from any additional Org features, like TODO notes,
>     Eli> calendar appointments, etc.  Just a document that includes structured
>     Eli> text.
> 
> None of those additional features are *required* for a document.

I'm not surprised.  But it could be that some minor feature will still
need something.  Like adding footnotes and links, perhaps?  It's all
should become clear once composing documents with Org is documented.

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 24 Apr 2020 15:32:26 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Fri, 24 Apr 2020 14:23:16 +0200
    >> Cc: joostkremers@fastmail.fm, rms@gnu.org, mail@nicolasgoaziou.fr,
    >> emacs-devel@gnu.org
    >> 
    Eli> That's orthogonal.  By "stand-alone" I meant a document that doesn't
    Eli> require support from any additional Org features, like TODO notes,
    Eli> calendar appointments, etc.  Just a document that includes structured
    Eli> text.
    >> 
    >> None of those additional features are *required* for a document.

    Eli> I'm not surprised.  But it could be that some minor feature will still
    Eli> need something.  Like adding footnotes and links, perhaps?  It's all
    Eli> should become clear once composing documents with Org is documented.

Itʼs all text, so you can add those manually if desired. But org by
default has keybindings for both of them :-)

Robert

Re: "Why is emacs so square?"

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Etc., etc.  I invite you to put yourself in the shows of a newcomer to
> Org, and try to imagine how such a newcomer will be able to realize
> that Org can be used as a word-processor...
>
> So please don't be surprised that Richard thinks about this what he
> thinks.

+1.  I used Emacs for a long time, but I didn't adopt Org until a long
time after its release (2013, 14 or so) or so, and even then the manual
was showing its age.

Re: "Why is emacs so square?"

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

Editing error: I sent

  > I found it impossible to learn what Org mode does.  Its introduction
  > taught how to do outline editing.  It made sense, but outline editing
  > useful for me, so I stopped reading.  I did not want to study use of a
  > mode for outline editing.

but I meant to send:

  > I found it impossible to learn what Org mode does.  Its introduction
  > taught how to do outline editing.  It made sense, but outline editing -
  > is not useful for me, so I stopped reading.  I did not want to study use of a
  > mode for outline editing.


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

Re: "Why is emacs so square?"

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> What I had in mind, regarding variable-pitch text, was word processing.

I was referring to how such features would allow people to potentially
create nicer (well, mostly) graphical interfaces inside Emacs, which
would in turn make Emacs appeal more in the minds of those who judge a
book by its cover.

Word processing in Emacs would also be nice.

Re: "Why is emacs so square?"

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> ndame <ndame@protonmail.com> writes:
>
>> I agree that Emacs is easier to program once you learned it, but
>> other editors, like VSCode, has the advantage that you don't have to
>> learn a quirky and unfamiliar language first.
>
>> Many developers know Javascript and even if one doesn't it's more similar
>> to mainstream languages than lisp, so extension writers mostly has to
>> learn the VSCode API only.
>
> Here's the problem: You have to learn the VS Code API. I'd say learning
> that, and becoming reasonably proficient at it takes longer than
> skimming through the Emacs Lisp intro.

Skimming the Emacs Lisp intro doesn’t make one reasonably proficient in
programming Emacs packages though. For one to understand how Emacs works
(with it’s obscure naming scheme like windows), one has to jump a lot of
hoops, and I can guarantee that one who is familiar with Algol-family
languages can pick up the VSCode API much faster than picking up Lisp,
Emacs, and the Emacs API.

>> VScode has a very nice out of the box experience. If you want support
>> for a language then it's one click to install it and it installs the
>> necessary scaffolding too, like a language server for the language.
>
> We have several starter packs, with similarly nice OOTB experiences.

But the default Emacs doesn’t have that, and that’s the problem.
Which means that, for one to have nice OOTB experiences, one has to have
a really good reason to use Emacs (like learning Common Lisp), then google
how to configure Emacs, then encounter Spacemacs without knowing anything
about evil or helm or ivy. And proficient Emacs users usually recommend
not using a starter kit in the internet. (That’s my experience on trying
to use Emacs.)

>> And it has Electron for display support which has a mature browser
>> engine behind it, so it can support advanced graphics features out
>> of the box on all the supported platforms.
>
> Electron is not free software (https://labs.parabola.nu/issues/1167),
> and is definitely not as well suited to providing an integrated
> experience like Emacs.

I don’t think OP was saying that we should use Electron for Emacs, but more
that due to using Electron, it gives the stability that Emacs doesn’t give.
Maybe you’ve only used Emacs on Linux, but at least on macOS, Emacs glitches,
locks, and crashes very frequently, and that’s a non-starter for a lot of  
people.

> For instance, even if you render raw HTML inside VS Code, you would not
> be able to grab the region using VSC APIs.  I'm not sure if the VSC API
> allows interacting with the DOM, but from what I can tell, it can't.
>
> There are also various other issues, with relying on a lower-level
> abstraction for "nice graphics features" (the DOM) that is outside the
> editors control.
>
>> Out of the box experience matters. Familiarity matters (e.g supporting
>> standard keys on the platfrom for cut and paste). Nice appearance matters.
>
> We have Cua mode.  No, you don't need to have it enabled by default,
> since it would result in unnecessary breakage for old users.  It would
> be nice if the startup screen informed users of features such as the
> (hypothetical) GTK theme previously mentioned, and Cua.
>
> I personally think that the Emacs bindings are better, and in the end
> work better with Emacs itself, but I do agree that newcomers should be
> allowed to familiarize themselves with Emacs before moving their
> workflow (and habits) to it entirely.
>
>> No wonder lot of developers choose VScode:
>> https://trends.google.com/trends/explore?geo=US&q=emacs%20editor,visual%20studio%20code
>
> We're here to change that :)

Re: "Why is emacs so square?"

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> Skimming the Emacs Lisp intro doesn’t make one reasonably proficient in
> programming Emacs packages though. For one to understand how Emacs works
> (with it’s obscure naming scheme like windows), one has to jump a lot of
> hoops, and I can guarantee that one who is familiar with Algol-family
> languages can pick up the VSCode API much faster than picking up Lisp,
> Emacs, and the Emacs API.

This is what gets interesting: Emacs Lisp is a language in it's own
right, and the "Emacs API" is the Emacs Lisp language.  Emacs Lisp is
also a rather small and simple language.

You don't have to pick up "Lisp", or the Emacs "API", you only
pick up Emacs Lisp.

> But the default Emacs doesn’t have that, and that’s the problem.
> Which means that, for one to have nice OOTB experiences, one has to have
> a really good reason to use Emacs (like learning Common Lisp), then google
> how to configure Emacs, then encounter Spacemacs without knowing anything
> about evil or helm or ivy. And proficient Emacs users usually recommend
> not using a starter kit in the internet. (That’s my experience on trying
> to use Emacs.)

We could put a link to them somewhere, but that's something for RMS to decide.

> I don’t think OP was saying that we should use Electron for Emacs, but more
> that due to using Electron, it gives the stability that Emacs doesn’t give.
> Maybe you’ve only used Emacs on Linux, but at least on macOS, Emacs glitches,
> locks, and crashes very frequently, and that’s a non-starter for a lot
> of people.

If it "glitches, crashes, locks", that's a bug, and instead of treating
it as a fact, report it.  Plus, I know a lot of people who use Emacs on
macOS, and I even had to use Emacs on Windows a long time back, and
Emacs has always been rather solid.  The starter packs are also supposed
to work well, and it might also be a problem with your own config.

OTOH, Lisp code shouldn't be able to make Emacs crash (unless you're
doing stuff like running invalid bytecode, or overflowing the GC stack),
and if it does, it's also a bug that should be fixed.

Re: "Why is emacs so square?"

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

When I said
> We could put a link to them somewhere, but that's something for RMS to
> decide

I meant
> We could put a link to them somewhere, but that's probably something
> for RMS to decide

Re: "Why is emacs so square?"

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> 조성빈 <pcr910303@icloud.com> writes:
>
>> Skimming the Emacs Lisp intro doesn’t make one reasonably proficient in
>> programming Emacs packages though. For one to understand how Emacs works
>> (with it’s obscure naming scheme like windows), one has to jump a lot of
>> hoops, and I can guarantee that one who is familiar with Algol-family
>> languages can pick up the VSCode API much faster than picking up Lisp,
>> Emacs, and the Emacs API.
>
> This is what gets interesting: Emacs Lisp is a language in it's own
> right, and the "Emacs API" is the Emacs Lisp language.  Emacs Lisp is
> also a rather small and simple language.

Emacs Lisp as a language and the standard library (the Emacs API) is
different. For example, the fact that functions and variables have their
own namespaces is a part of the language, and the functions
self-insert-command or bury-buffer are parts of the API.

You can call them as a whole Emacs Lisp, but that doesn’t mean that
it’s more easier/simple than VSCode. Yes, Emacs Lisp isn’t a complex
language like C++, but for outsiders that have never used Lisp, it’s
hard to approach.

Regardless, Emacs can’t stop using Emacs Lisp, so Emacs needs to be the
reason for users to use Emacs Lisp, not backwards. And that means that
Emacs should have a great onboarding experience (which is currently not true)
with various packages for so many languages and productivity tools (which is
IMHO true considering all of the packages in GitHub).

> You don't have to pick up "Lisp", or the Emacs "API", you only
> pick up Emacs Lisp.
>
>> But the default Emacs doesn’t have that, and that’s the problem.
>> Which means that, for one to have nice OOTB experiences, one has to have
>> a really good reason to use Emacs (like learning Common Lisp), then google
>> how to configure Emacs, then encounter Spacemacs without knowing anything
>> about evil or helm or ivy. And proficient Emacs users usually recommend
>> not using a starter kit in the internet. (That’s my experience on trying
>> to use Emacs.)
>
> We could put a link to them somewhere, but that's probably something for
> RMS to decide.

Yes, it would be very useful if we can include some links to the starter  
kits.
Also, it would be great if Emacs can have a default init.el that gets  
generated
when there is no one, so that first time users don’t get a bad impression.

>> I don’t think OP was saying that we should use Electron for Emacs, but  
>> more
>> that due to using Electron, it gives the stability that Emacs doesn’t  
>> give.
>> Maybe you’ve only used Emacs on Linux, but at least on macOS, Emacs  
>> glitches,
>> locks, and crashes very frequently, and that’s a non-starter for a lot
>> of people.
>
> If it "glitches, crashes, locks", that's a bug, and instead of treating
> it as a fact, report it.

I know, I should report it, but I find that macOS/Windows is considered a
second-platform here, and I didn't want to take my time writing reports just
to get no feedback. I’ll try to report some today.

(TBF, I remember trying to report them, searching for duplicates, and I saw  
some
bug report on the exact same issue I was experiencing. I didn’t know how to
subscribe, so I just thought that it might get fixed.)

> Plus, I know a lot of people who use Emacs on
> macOS, and I even had to use Emacs on Windows a long time back, and
> Emacs has always been rather solid.  The starter packs are also supposed
> to work well, and it might also be a problem with your own config.
>
> OTOH, Lisp code shouldn't be able to make Emacs crash (unless you're
> doing stuff like running invalid bytecode, or overflowing the GC stack),
> and if it does, it's also a bug that should be fixed.

Re: "Why is emacs so square?"

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:


> Emacs Lisp as a language and the standard library (the Emacs API) is
> different. For example, the fact that functions and variables have their
> own namespaces is a part of the language, and the functions
> self-insert-command or bury-buffer are parts of the API.

Do buffer-local variables count as part of the language, or part of the
API? What about text properties in strings? File-local variables?
Primitives like `record_unwind_protect_excursion`? Or how the bytecode
interpreter has a plethora of primitives that only make sense within
Emacs.

And I would consider `self-insert-command' part of Emacs Lisp the
language, since it is implemented as a subr in C code.

> You can call them as a whole Emacs Lisp, but that doesn’t mean that
> it’s more easier/simple than VSCode. Yes, Emacs Lisp isn’t a complex
> language like C++, but for outsiders that have never used Lisp, it’s
> hard to approach.

It's not hard to approach at all.  The easy trick is to treat it as an
editor macro language, instead of a Lisp dialect.
> Regardless, Emacs can’t stop using Emacs Lisp, so Emacs needs to be the
> reason for users to use Emacs Lisp, not backwards. And that means that
> Emacs should have a great onboarding experience (which is currently not true)
> with various packages for so many languages and productivity tools (which is
> IMHO true considering all of the packages in GitHub).

Emacs Lisp (more precisely, the first-class extensiblity) is one of the
main reasons to choose Emacs, and the onboarding experience is exactly
what we're talking about.

> I know, I should report it, but I find that macOS/Windows is considered a
> second-platform here, and I didn't want to take my time writing reports just
> to get no feedback. I’ll try to report some today.

macOS/Windows are considered second-class platforms, when it comes to
features: features not available on free operating systems will not be
available on non-free systems.  macOS/Windows are not second-class
platforms, when it comes to fixing bugs not present on free operating
systems.

> (TBF, I remember trying to report them, searching for duplicates, and
> I saw some
> bug report on the exact same issue I was experiencing. I didn’t know how to
> subscribe, so I just thought that it might get fixed.)

Hm, you can always M-x report-emacs-bug

Re: "Why is emacs so square?"

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> 조성빈 <pcr910303@icloud.com> writes:
>
>
>> Emacs Lisp as a language and the standard library (the Emacs API) is
>> different. For example, the fact that functions and variables have their
>> own namespaces is a part of the language, and the functions
>> self-insert-command or bury-buffer are parts of the API.
>
> Do buffer-local variables count as part of the language, or part of the
> API? What about text properties in strings? File-local variables?
> Primitives like `record_unwind_protect_excursion`? Or how the bytecode
> interpreter has a plethora of primitives that only make sense within
> Emacs.
>
> And I would consider `self-insert-command' part of Emacs Lisp the
> language, since it is implemented as a subr in C code.

I was arguing that the surface area of Emacs is not smaller than VSCode,
which makes the exact classification unnecessary.

(FYI, I count buffer-local vars as a property of the runtime, text
properties are definitely an Emacs API, and `record_unwind_protect_excursion`
or other primitives, subrs like `self-insert-command` written in C are all
Emacs APIs. The language are things like if-expressions, macros, symbols,  
etc…)

>> You can call them as a whole Emacs Lisp, but that doesn’t mean that
>> it’s more easier/simple than VSCode. Yes, Emacs Lisp isn’t a complex
>> language like C++, but for outsiders that have never used Lisp, it’s
>> hard to approach.
>
> It's not hard to approach at all.  The easy trick is to treat it as an
> editor macro language, instead of a Lisp dialect.

I spread Emacs to my friends. Unless ones who already know Common Lisp,
almost everyone feels that Emacs Lisp is a big hoop.

>> Regardless, Emacs can’t stop using Emacs Lisp, so Emacs needs to be the
>> reason for users to use Emacs Lisp, not backwards. And that means that
>> Emacs should have a great onboarding experience (which is currently not  
>> true)
>> with various packages for so many languages and productivity tools  
>> (which is
>> IMHO true considering all of the packages in GitHub).
>
> Emacs Lisp (more precisely, the first-class extensiblity) is one of the
> main reasons to choose Emacs, and the onboarding experience is exactly
> what we're talking about.

First class extensibility is probably one of the big reason to use Emacs, but
that’s orthogonal to Emacs Lisp. And I can’t say that the onboarding  
experience
is really about Emacs Lisp - users don’t try to add keybindings or custom
functions on the first day of use.

>> I know, I should report it, but I find that macOS/Windows is considered a
>> second-platform here, and I didn't want to take my time writing reports  
>> just
>> to get no feedback. I’ll try to report some today.
>
> macOS/Windows are considered second-class platforms, when it comes to
> features: features not available on free operating systems will not be
> available on non-free systems.  macOS/Windows are not second-class
> platforms, when it comes to fixing bugs not present on free operating
> systems.
>
>> (TBF, I remember trying to report them, searching for duplicates, and
>> I saw some
>> bug report on the exact same issue I was experiencing. I didn’t know how  
>> to
>> subscribe, so I just thought that it might get fixed.)
>
> Hm, you can always M-x report-emacs-bug

Re: "Why is emacs so square?"

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> (FYI, I count buffer-local vars as a property of the runtime, text
> properties are definitely an Emacs API, and `record_unwind_protect_excursion`
> or other primitives, subrs like `self-insert-command` written in C are all
> Emacs APIs. The language are things like if-expressions, macros,
> symbols, etc…)

Here's the problem: primitives like buffer-local variables, text
properties, and record_unwind_protect_excursion, and self-insert-command
all depend on Emacs concepts such as "buffers", "windows", "frames" and
on and on.  All of these are implemented as language primitives (and in
many cases, 'properties of the runtime', et cetera).  The Lisp
interpreter itself intermingles with "editor" code in a highly haphazard
and ad-hoc way, with many "APIs" being implemented as core language
constructs.

My view is: if the language still makes sense when X construct is
removed, X construct is considered outside the language.  If it doesn't,
X is part of the language.

> I spread Emacs to my friends. Unless ones who already know Common Lisp,
> almost everyone feels that Emacs Lisp is a big hoop.

You're not spreading it right, then :)
The Eintr teaches Emacs Lisp to non-programmers very well.  It also
teaches them how to extend the editor, in a straight-forward and
easy-to-understand way.


> First class extensibility is probably one of the big reason to use Emacs, but
> that’s orthogonal to Emacs Lisp. And I can’t say that the onboarding
> experience
> is really about Emacs Lisp - users don’t try to add keybindings or custom
> functions on the first day of use.

The reason Emacs extensiblity is so first-class is because functionality
for extending Emacs are implemented as primitives in the editor, and are
not "APIs" grafted on top of other languages, such as VS Code or
whatever.

Re: "Why is emacs so square?"

[ndame]

>
> You're not spreading it right, then :)
> The Eintr teaches Emacs Lisp to non-programmers very well. It also
> teaches them how to extend the editor, in a straight-forward and
> easy-to-understand way.

Are these materials available somewhere?

Re: "Why is emacs so square?"

[Po Lu]

ndame <ndame@protonmail.com> writes:

>>
>> You're not spreading it right, then :)
>> The Eintr teaches Emacs Lisp to non-programmers very well. It also
>> teaches them how to extend the editor, in a straight-forward and
>> easy-to-understand way.
>
> Are these materials available somewhere?

C-h i m Emacs Lisp Intro RET

Re: "Why is emacs so square?"

[ndame]

> >
> > Are these materials available somewhere?
>
> C-h i m Emacs Lisp Intro RET

Ah, I didn't get what Eintr refers to. I thought there were some new course
for laypeople to learn emacs.

Re: "Why is emacs so square?"

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> 조성빈 <pcr910303@icloud.com> writes:
>
>> (FYI, I count buffer-local vars as a property of the runtime, text
>> properties are definitely an Emacs API, and  
>> `record_unwind_protect_excursion`
>> or other primitives, subrs like `self-insert-command` written in C are all
>> Emacs APIs. The language are things like if-expressions, macros,
>> symbols, etc…)
>
> Here's the problem: primitives like buffer-local variables, text
> properties, and record_unwind_protect_excursion, and self-insert-command
> all depend on Emacs concepts such as "buffers", "windows", "frames" and
> on and on.  All of these are implemented as language primitives (and in
> many cases, 'properties of the runtime', et cetera).  The Lisp
> interpreter itself intermingles with "editor" code in a highly haphazard
> and ad-hoc way, with many "APIs" being implemented as core language
> constructs.
>
> My view is: if the language still makes sense when X construct is
> removed, X construct is considered outside the language.  If it doesn't,
> X is part of the language.

I personally think that various Emacs APIs regarding buffers, etc… is not
part of the language, but that’s just my opinion.

>> I spread Emacs to my friends. Unless ones who already know Common Lisp,
>> almost everyone feels that Emacs Lisp is a big hoop.
>
> You're not spreading it right, then :)
> The Eintr teaches Emacs Lisp to non-programmers very well.  It also
> teaches them how to extend the editor, in a straight-forward and
> easy-to-understand way.

No, people shouldn't need to learn a new language to use an editor.
In the ideal world, normal people should be able to use package.el and
custom.el to use Emacs without much fuss, and some people that is
interested in can develop packages.

It’s just that Emacs practically needs configuration to be usable - which
means that one must learn Emacs lisp.

Yes, Eintr teaches Emacs Lisp well, but that step should be optional.

>> First class extensibility is probably one of the big reason to use  
>> Emacs, but
>> that’s orthogonal to Emacs Lisp. And I can’t say that the onboarding
>> experience
>> is really about Emacs Lisp - users don’t try to add keybindings or custom
>> functions on the first day of use.
>
> The reason Emacs extensiblity is so first-class is because functionality
> for extending Emacs are implemented as primitives in the editor, and are
> not "APIs" grafted on top of other languages, such as VS Code or
> whatever.

Re: "Why is emacs so square?"

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> I personally think that various Emacs APIs regarding buffers, etc… is not
> part of the language, but that’s just my opinion.

They're implemented inside the language runtime, have relavant
primitives inside the bytecode engine, et cetera.  They're also the
primary (I wouldn't go as far as to say only, but it's close) IO
mechanism available in Emacs Lisp.

> No, people shouldn't need to learn a new language to use an editor.
> In the ideal world, normal people should be able to use package.el and
> custom.el to use Emacs without much fuss, and some people that is
> interested in can develop packages.

Indeed, normal people can do exactly that even today.  The point I'm
making here is that learning Emacs Lisp itself will let you extend
Emacs, and that there's no extra "Emacs API" to learn.

> It’s just that Emacs practically needs configuration to be usable - which
> means that one must learn Emacs lisp.
>
> Yes, Eintr teaches Emacs Lisp well, but that step should be optional.

And it is optional; You can go by with package+custom fairly well.  I
know people who do that.

Re: "Why is emacs so square?"

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

  > > I personally think that various Emacs APIs regarding buffers, etc… is not
  > > part of the language, but that’s just my opinion.

  > They're implemented inside the language runtime, have relavant
  > primitives inside the bytecode engine, et cetera.  They're also the
  > primary (I wouldn't go as far as to say only, but it's close) IO
  > mechanism available in Emacs Lisp.

Those are not part of the Lisp language, so they are not really
part of the mission of the Lisp Reference Manual.
It does document some internal C conventions because they are useful
for people who want to customize at the C level, but we do that
only to the extent that seems worth doing.


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

Re: "Why is emacs so square?"

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Those are not part of the Lisp language, so they are not really
> part of the mission of the Lisp Reference Manual.
> It does document some internal C conventions because they are useful
> for people who want to customize at the C level, but we do that
> only to the extent that seems worth doing.

I'm just saying that I would consider buffers part of Emacs Lisp, and
not a separate "Emacs Lisp standard library".

Re: "Why is emacs so square?"

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

  > I'm just saying that I would consider buffers part of Emacs Lisp, and
  > not a separate "Emacs Lisp standard library".

The Emacs Lisp Reference Manual documents the use of buffers
from Emacs Lisp.  Operating on them with C code is a different matter.

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

Re: "Why is emacs so square?"

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> The Emacs Lisp Reference Manual documents the use of buffers
> from Emacs Lisp.  Operating on them with C code is a different matter.

I wasn't referring to how buffers can be operated from C code.  I was
referring to how buffers are an integral part of the Emacs Lisp
*language*, and not some hypothetical "standard library".

I was also referring to how the Eintr explains how buffers can be
manipulated from Lisp code quite well.

Re: "Why is emacs so square?"

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

  > I wasn't referring to how buffers can be operated from C code.  I was
  > referring to how buffers are an integral part of the Emacs Lisp
  > *language*, and not some hypothetical "standard library".

I don't think the concept of "standard library" makes sense for Emacs
Lisp.  However, I conceptually divide the programming facilities
of Emacs into 

* The Emacs Lisp language

and

* the editing facilities.

I see buffers as part of the editing facilities, not part of the Emacs
Lisp language itself.

  > I was also referring to how the Eintr explains how buffers can be
  > manipulated from Lisp code quite well.

What do you mean by the term "Eintr"?

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

Re: "Why is emacs so square?"

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> I don't think the concept of "standard library" makes sense for Emacs
> Lisp.  However, I conceptually divide the programming facilities
> of Emacs into 
>
> * The Emacs Lisp language
>
> and
>
> * the editing facilities.

> I see buffers as part of the editing facilities, not part of the Emacs
> Lisp language itself.

I'm not sure I see that distinction, since Emacs Lisp as a language
doesn't really make sense without the editing facilities.  It would make
sense to classify Emacs Lisp as a whole as a highly domain-centric Lisp dialect.

> What do you mean by the term "Eintr"?

The book "An Introduction to Programming in Emacs Lisp"

Re: "Why is emacs so square?"

[Stefan Monnier]

>> I don't think the concept of "standard library" makes sense for Emacs
>> Lisp.  However, I conceptually divide the programming facilities
>> of Emacs into 
>>
>> * The Emacs Lisp language
>>
>> and
>>
>> * the editing facilities.

Because of how it evolved, there is clear separation.
And it's hard to retro-fit a distinction after-the-fact.
But I personally do think of the Elisp world as split into various "layers":

A- The core language itself.
B- The core standard library.
C- Extra libraries bundled with Emacs.
D- Extra libraries distributed in GNU ELPA.
E- Extra libraries distributed elsewhere.

Yet, I would be hard pressed to draw the separation between some of
those layers (and more so to "define" that separation).

>> I see buffers as part of the editing facilities, not part of the Emacs
>> Lisp language itself.

Great example: putting it in (B) makes sense, yet at the same time I'd
put buffer-local variables in (A), thus breaking the layering.

> I'm not sure I see that distinction, since Emacs Lisp as a language
> doesn't really make sense without the editing facilities.

There are other implementations of Elisp, some of which are not tied to
an editor, so it can make sense (see the paper Mike Sperber and I wrote
for HOPL-2020 for an example).  


        Stefan

Re: "Why is emacs so square?"

[Po Lu]

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


> Because of how it evolved, there is clear separation.
> And it's hard to retro-fit a distinction after-the-fact.
> But I personally do think of the Elisp world as split into various "layers":
>
> A- The core language itself.
> B- The core standard library.

Are you referring to `subr.el' and friends, or built-in primitives, or
subrs in *fns.c, or both, or all three?

> Great example: putting it in (B) makes sense, yet at the same time I'd
> put buffer-local variables in (A), thus breaking the layering.

Precisely.

> There are other implementations of Elisp, some of which are not tied to
> an editor, so it can make sense (see the paper Mike Sperber and I wrote
> for HOPL-2020 for an example).  

Of the many implementations that I see listed there, most are from the
"let's rewrite Emacs (in our favorite language / better)" camp, and do
include some (or most of) the editing primitives.  Of the others, I
don't really see Emacs Lisp, but a glorified MacLISP with optional
lexical binding and some Emacs Lisp-ish features.

I suppose we're operating on different definitions of what constitutes
"Emacs Lisp".

Re: "Why is emacs so square?"

[Stefan Monnier]

> Of the many implementations that I see listed there, most are from the
> "let's rewrite Emacs (in our favorite language / better)" camp, and do
> include some (or most of) the editing primitives.  Of the others, I
> don't really see Emacs Lisp, but a glorified MacLISP with optional
> lexical binding and some Emacs Lisp-ish features.

I was thinking mostly of the "elisp.lisp" package by Sam Steingold (and
to a lesser extent librep).

> I suppose we're operating on different definitions of what constitutes
> "Emacs Lisp".

I know for a fact that I operate on several different definitions of
what constitutes "Elisp", yes  ;-)


        Stefan

Re: "Why is emacs so square?"

[Po Lu]

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

> I know for a fact that I operate on several different definitions of
> what constitutes "Elisp", yes  ;-)

Fair enough, then.  Thanks for clearing it up.

Re: "Why is emacs so square?"

[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 do you mean by the term "Eintr"?

  > The book "An Introduction to Programming in Emacs Lisp"

I was surprised to see that term used in connection with Emacs.
Is that name for the manual used in any part of Emacs?

I recognize EINTR only as an error code for system calls. ;-{.

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

Re: "Why is emacs so square?"

[Eduardo Ochs]

Hi Richard,
this sexp
  (info "(eintr)Top")
opens the manual "An Introduction to Programming in Emacs Lisp".

On Fri, 24 Apr 2020 at 03:35, Richard Stallman <rms@gnu.org> wrote:
> I was surprised to see that term used in connection with Emacs.
> Is that name for the manual used in any part of Emacs?
>
> I recognize EINTR only as an error code for system calls. ;-{.

Re: "Why is emacs so square?"

[Kévin Le Gouguec]

Richard Stallman <rms@gnu.org> writes:

>   > > What do you mean by the term "Eintr"?
>
>   > The book "An Introduction to Programming in Emacs Lisp"
>
> I was surprised to see that term used in connection with Emacs.
> Is that name for the manual used in any part of Emacs?

This comment in doc/lispintro/Makefile seem to point to hysterical
raisins:

#+begin_src makefile
srcs = ${srcdir}/emacs-lisp-intro.texi ${srcdir}/doclicense.texi \
  ${emacsdir}/docstyle.texi ${emacsdir}/emacsver.texi

# …

# The file name eintr must fit within 5 characters, to allow for
# -NN extensions to fit into DOS 8+3 limits without clashing.
${buildinfodir}/eintr.info: ${srcs} | ${buildinfodir}
	$(AM_V_GEN)$(MAKEINFO) $(MAKEINFO_OPTS) $(INFO_OPTS) -o $@ $<
#+end_src

Re: "Why is emacs so square?"

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

  > # The file name eintr must fit within 5 characters, to allow for
  > # -NN extensions to fit into DOS 8+3 limits without clashing.

Thanks for finding the reason.

Eli, does this name length matter any more?

Is the Emacs Lisp Intro long enough that it needs to generate subfiles
named with two digits?  Could we make it generate suffixes -N instead?
Then we could call it ELINTR.

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: me@enzu.ru, joseph.h.garvin@gmail.com, stefan@marxist.se,
> 	emacs-devel@gnu.org, luangruo@yahoo.com, pcr910303@icloud.com,
> 	eliz@gnu.org, drew.adams@oracle.com, ndame@protonmail.com
> Date: Fri, 24 Apr 2020 23:36:03 -0400
> 
>   > # The file name eintr must fit within 5 characters, to allow for
>   > # -NN extensions to fit into DOS 8+3 limits without clashing.
> 
> Thanks for finding the reason.
> 
> Eli, does this name length matter any more?

No.  Especially since we stopped splitting our manuals into foo-N
parts long ago.

The only issue today is that renaming the Info file will make the
successful update of the system-wide DIR file by install-info at "make
install" time more important, otherwise people might have an old
manual presented to them.  Not sure what this means for the various
binary distros.  Also, we need to rework all the references we have to
that manual in Lisp files (I found only one such reference, FWIW).

> Is the Emacs Lisp Intro long enough that it needs to generate subfiles
> named with two digits?  Could we make it generate suffixes -N instead?

Not an issue anymore, see above.

> Then we could call it ELINTR.

I'd suggest ELINTRO or even LISPINTRO (similar to LISPREF for the
ELisp reference manual).

Re: "Why is emacs so square?"

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

  > I'd suggest ELINTRO or even LISPINTRO (similar to LISPREF for the
  > ELisp reference manual).

Given we can use such a long name, I think LISPINTRO is good.

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: me@enzu.ru, joseph.h.garvin@gmail.com, stefan@marxist.se,
> 	emacs-devel@gnu.org, pcr910303@icloud.com, eliz@gnu.org,
> 	drew.adams@oracle.com, ndame@protonmail.com
> Date: Thu, 23 Apr 2020 22:34:27 -0400
> 
>   > > What do you mean by the term "Eintr"?
> 
>   > The book "An Introduction to Programming in Emacs Lisp"
> 
> I was surprised to see that term used in connection with Emacs.
> Is that name for the manual used in any part of Emacs?

It's the name of the Info file we produce from that manual:
eintr.info.

Re: "Why is emacs so square?"

[ndame]

>
> Here's the problem: You have to learn the VS Code API. I'd say learning
> that, and becoming reasonably proficient at it takes longer than
> skimming through the Emacs Lisp intro.

Learning lisp needs a new mindset while the VS Code API is just a bunch
of method calls.

And you don't need to learn the whole API. When I wrote an extension for
a test, to see how hard it is then I just googled things and used those
parts which I needed. I certanly didn't learn the whole vscode API, because
it wasn't necessary.

> > VScode has a very nice out of the box experience. If you want support
> > for a language then it's one click to install it and it installs the
> > necessary scaffolding too, like a language server for the language.
>
> We have several starter packs, with similarly nice OOTB experiences.

But they are not advertised on the emacs homepage, so a new user who just
googles emacs doesn't necessarily know about them.


>
> Electron is not free software (https://labs.parabola.nu/issues/1167),
> and is definitely not as well suited to providing an integrated
> experience like Emacs.

I know it's not free software. I just meant it provided many features
out of the box which has to be implemented separately for emacs.


> For instance, even if you render raw HTML inside VS Code, you would not
> be able to grab the region using VSC APIs. I'm not sure if the VSC API
> allows interacting with the DOM, but from what I can tell, it can't.

Certainly, it's more limited some ways, you don't have the freedom to
access everything like in Emacs.

>
> We have Cua mode. No, you don't need to have it enabled by default,
> since it would result in unnecessary breakage for old users.

Well, I think old users could adapt for the sake of new users. New users
shouldn't encounter lots of strange concepts from the start.

For example, the current tutorial may not be the best
approach. Explaining about cursor movement with C-f and C-b? Windows
and frames?

Why a new user who casually wants to try emacs has to start with this?

A new user can use the cursor keys and the mouse to operate the
menus. Rather than focusing on strange keys for cursor movement a
better approach could be explaining what emacs does better than other
tools and how to use those features.

And users could be informed on the startup screen that they can learn
traditional emacs keys in a separate tutorial if they are interested.

>
> I personally think that the Emacs bindings are better, and in the end
> work better with Emacs itself, but I do agree that newcomers should be
> allowed to familiarize themselves with Emacs before moving their
> workflow (and habits) to it entirely.

Exactly. Users should encounter a familiar environment first, using
the keys they are used to. They can always move on if they decide to
stay with emacs.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Sun, 19 Apr 2020 06:52:03 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Ahmed Khanzada <me@enzu.ru>, Stefan Kangas <stefan@marxist.se>,
>  Joseph Garvin <joseph.h.garvin@gmail.com>, Richard Stallman <rms@gnu.org>,
>  Emacs developers <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>,
>  Drew Adams <drew.adams@oracle.com>
> 
> For example, the current tutorial may not be the best
> approach. Explaining about cursor movement with C-f and C-b? Windows
> and frames?
> 
> Why a new user who casually wants to try emacs has to start with this?
> 
> A new user can use the cursor keys and the mouse to operate the
> menus. Rather than focusing on strange keys for cursor movement a
> better approach could be explaining what emacs does better than other
> tools and how to use those features.

When did you last look at the tutorial that comes with Emacs?  We
mention the cursor keys there since Emacs 22.1.  We mention
PageUp/PageDown since Emacs 23.1.

> And users could be informed on the startup screen that they can learn
> traditional emacs keys in a separate tutorial if they are interested.

We think using C-f/C-b etc. keys will help users type more
efficiently, and we say so in the tutorial, _after_ saying that the
"normal" cursor motion keys also work.  I see nothing wrong with that.

Re: "Why is emacs so square?"

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

I think you've stated the arguments very well.  There are a couple of
points where I would say something less strong.

  > 3. If Emacs was to become a "modern" app tomorrow, an editor extended
  > in Lisp still only has appeal for a minority of programmers, much like
  > the Lisp language itself. Most programmers looking for easy and modern
  > experiences will likely stick with Atom and Sublime.

If Emacs were 100% as convenient and attractive as other editors,
it is possible that a lot of users would use it.  30 years ago,
the user profile of Emacs was much broader than it is today.
It would be good to make this happen again.

But that would require a number of changes, and I don't think that
round corners would get us close to there.

Thus, I think your point 3 is not valid in the universal sense that it
is presented in, but it is valid for the this particular issue.

If there are people who want to work on rounded corners, and assuming
they do a good job, I won't argue against it.  But if you want
to attract more users to Emacs, I think there are more important
areas for improvement.

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

Re: "Why is emacs so square?"

[Po Lu]

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

Richard Stallman <rms@gnu.org> writes:

> If Emacs were 100% as convenient and attractive as other editors,
> it is possible that a lot of users would use it.  30 years ago,
> the user profile of Emacs was much broader than it is today.
> It would be good to make this happen again.

I would personally say that several of the starter packs (Spacemacs and
Doom immediately come to mind) are "attractive" and "modern", and don't
really sacrifice any functionality to achieve that.  Spacemacs is also
very easy to set-up and use.  (Doom's also getting there).
> But that would require a number of changes, and I don't think that
> round corners would get us close to there.

Agreed.

> If there are people who want to work on rounded corners, and assuming
> they do a good job, I won't argue against it.  But if you want
> to attract more users to Emacs, I think there are more important
> areas for improvement.

I'm working on something that uses GTK foreign rendering to draw button
and input field backgrounds as face boxes;  I should be able to get it
in a usable state soon (right now it only works on top of another set of
patches I'm working on that make Emacs a pure GTK app).


[-- Attachment #2: Screenshot --]
[-- Type: image/png, Size: 131103 bytes --]

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 19, 2020, at 11:33, Po Lu <luangruo@yahoo.com> wrote:
> 
>> If there are people who want to work on rounded corners, and assuming
>> they do a good job, I won't argue against it.  But if you want
>> to attract more users to Emacs, I think there are more important
>> areas for improvement.
> 
> I'm working on something that uses GTK foreign rendering to draw button
> and input field backgrounds as face boxes;  I should be able to get it
> in a usable state soon (right now it only works on top of another set of
> patches I'm working on that make Emacs a pure GTK app).

Maybe it would be nice to have era-based user experiences. Like a 70's UI package, a 80's UI package, etc. That way it is just a matter of selecting a package and every generation will feel that emacs is just what works for them. Just half (maybe quarter) tongue in cheek.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

[Po Lu]

Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
writes:

> Maybe it would be nice to have era-based user experiences. Like a 70's
> UI package, a 80's UI package, etc. That way it is just a matter of
> selecting a package and every generation will feel that emacs is just
> what works for them. Just half (maybe quarter) tongue in cheek.

I'm not sure that's necessary.  It makes sense to have a set of well
thought-out defaults that work for everyone, or perhaps a few extra
custom themes (ie `gtk') that enable these options and are bundled with
Emacs by default.

Re: "Why is emacs so square?"

[ndame]

>
> I'm working on something that uses GTK foreign rendering to draw button
> and input field backgrounds as face boxes; I should be able to get it
> in a usable state soon (right now it only works on top of another set of
> patches I'm working on that make Emacs a pure GTK app).

Looks good. These are the changes Emacs needs, so it has a nicer first
impression for users who come from mainstream tools to give it a try.

Emacs shouldn't look old fashioned out of the box. It would be great
if it could use GTK widgets on all major GUI platforms, instead of
text buttons and stuff.

Re: "Why is emacs so square?"

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> I'm working on something that uses GTK foreign rendering to draw button
> and input field backgrounds as face boxes;  I should be able to get it
> in a usable state soon

Interesting.  Can you use all the normal editing commands inside the
text field widget?

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

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

  > * A UI that doesn't look or behave like any other application
  > * Keyboard shortcuts inconsistent with every other application
  > * A bizarre ancient vocabulary inconsistent with every other application.

A new user might well think of Emacs keyboard commands as "shortcuts",
carrying over the concepts that perse has learned in using other
programs.  When it comes to understanding what new users think,
we need to know what concepts they use.

But those characters are not really "shortcuts".

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

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 16, 2020, at 23:58, Drew Adams <drew.adams@oracle.com> wrote:
> 
> And count me as one vote for the menu-bar being
> important, especially for discoverability.  The
> tool-bar is less important, IMO, but I'd still
> vote to keep it.

The tool bar especially would work better if it looked/acted like it were native.



Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

RE: "Why is emacs so square?"

[Drew Adams]

> The tool bar especially would work better if it
> looked/acted like it were native.

I suppose I can guess what you mean by "looking"
native, but not what "acting" native means.

My impression is that different apps outside Emacs
can have radically different kinds of tool bars,
both wrt action and look & feel.  And this is so,
even for apps on the same platform, where they are
perhaps all "native".

IMHO, the Emacs tool-bar is something that it makes
sense - at least optionally - to pop up on demand,
rather than take up a fair amount of screen real
estate.

My library tool-bar+.el implements one way of doing
this - by having a menu-bar pseudo-menu `Buttons',
which, when clicked, shows the tool-bar only for one
operation.  Other ways of doing this or something
similar are possible, of course.

https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus

(That library also gives you the possibility of
showing the tool-bar only on particular frames,
rather than showing it on all frames or not showing
it on any frame.)

Re: "Why is emacs so square?"

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

  > The tool bar especially would work better if it looked/acted like it were native.

Can you explain how that change in appearance would make it _work_ better?

I can understand claiming that people would feel more comfortable with it.

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

Re: "Why is emacs so square?"

[ndame]

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

> This is because GTK+ has a bug that AFAIR they don't intend to fix
> because they don't consider our use of GTK+ important enough (or
> correct, for that matter).

Is it hard to fix the GTK side in Emacs, so it uses GTK correctly as
the GTK developers intended, so the bug doesn't occur?

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Thu, 16 Apr 2020 11:16:13 +0000
> From: ndame <ndame@protonmail.com>
> 
> > This is because GTK+ has a bug that AFAIR they don't intend to fix
> > because they don't consider our use of GTK+ important enough (or
> > correct, for that matter).
> 
> Is it hard to fix the GTK side in Emacs, so it uses GTK correctly as
> the GTK developers intended, so the bug doesn't occur?

Yes.

Re: "Why is emacs so square?"

[ndame]

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

> Oh yes, because everyone chooses Emacs for hipster graphics
> rather than for a free, sophisticated tool that lets you get
> work done.

You may not care about visual appearance, but many people do and they want a tool which is pleasant to look at.

Even on the Emacs subreddit which is a place for active Emacs users people often post packages which pimp up Emacs:

https://preview.redd.it/nu0zfp2rcds41.png?width=1072&format=png&auto=webp&s=6913236a90c2315dcddd4a4224f7d72b1ab19d19

https://i.imgur.com/ZJW9UN4.png

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

"Why is emacs so square?"

[ndame]

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

A user on reddit asked this once and he was not wrong, because
emacs does seem blocky compared to modern designs, which often employs
rounded corners, e.g for buttons:

https://www.webdesignerwall.com/wp-content/uploads/2010/04/button-preview.jpg

It could improve the square apperance if, for example, emacs provided some text
properties to specify rounded corners with custom radius for background colors.

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

Re: "Why is emacs so square?"

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

Perhaps we should implement a mode that puts cosmetics on Emacs
so it will appeal to those who judge by the surface of things.

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

Re: "Why is emacs so square?"

[ndame]

>
> Perhaps we should implement a mode that puts cosmetics on Emacs
> so it will appeal to those who judge by the surface of things.
>

Visual impression matters. Often when I showed Emacs to people they commented on how dated it looks.

If Emacs' appearance can be improved by small things like providing support for rounded corners then it can be more appealing for people who care about visual appearance.

Re: "Why is emacs so square?"

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> Perhaps we should implement a mode that puts cosmetics on Emacs

Is there any reason not to improve the default look?

> so it will appeal to those who judge by the surface of things.

I think it's unfortunate if we assume that this is all bells and
whistles.  Graphical design elements can also improve usability.

I also don't know that it's helpful to assume that the rest of the
world will take the enlightened stance.  For example, I've always
assumed that many people use Sublime Text not due to any serious
feature comparison with Emacs, but because they like its "sleek look".
I don't suggest that we should imitate proprietary junk editor <foo>,
but we should realize that these things are not wholly unimportant.

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[ndame]

> Richard Stallman rms@gnu.org writes:
>
> > Perhaps we should implement a mode that puts cosmetics on Emacs
>
> Is there any reason not to improve the default look?

When people say to me Emacs looks dated I often think the FSF should look for a graphics designer to improve the default appearance of Emacs.

Perhaps there are some who are sympatethic to the free software cause and they would do it even for free.

Re: "Why is emacs so square?"

[Emanuel Berg via Emacs development discussions.]

Stefan Kangas wrote:

> I also don't know that it's helpful to assume that the
> rest of the world will take the enlightened stance.
> For example, I've always assumed that many people use
> Sublime Text not due to any serious feature comparison
> with Emacs, but because they like its "sleek look".
> I don't suggest that we should imitate proprietary
> junk editor <foo>, but we should realize that these
> things are not wholly unimportant.

Tour de France/Giro d'Italia road race bikes look
stylish AND are fast.

UCI track cycling bikes look cool and futuristic AND
are fast.

etc etc

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

Re: "Why is emacs so square?"

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

  > Is there any reason not to improve the default look?

1. It will take work.

2. The code to interface Emacs to X-based GUIs needs rewriting by an
expert, and has needed it for decades.  Until it gets that rewrite,
changes in it are likely to break something.

3. We may not have any developers who are experts on that area
and capable of doing any changes well.

    > Graphical design elements can also improve usability.

I won't argue with that -- but I have a feeling that the changes
that would help are deeper issues than the shape of corners.

  >   For example, I've always
  > assumed that many people use Sublime Text not due to any serious
  > feature comparison with Emacs, but because they like its "sleek look".

Perhaps that is true.  Or perhaps its graphical interface is
substantively more natural than that of Emacs.  In Emacs, our
graphical interface is constrained by historical compatibility
and making it more natural is difficult.

Another question about them: are they among the segment of users for
whom the investment of learning Emacs would pay off?


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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 15 Apr 2020 22:30:20 -0400
> Cc: emacs-devel@gnu.org, ndame@protonmail.com
> 
> Another question about them: are they among the segment of users for
> whom the investment of learning Emacs would pay off?

I don't really know the answer, but I'd like to remind all of us that
there's a lot of "propaganda" out there telling everyone to turn off
GUI features such as the menu bar and the tool bar.  The network is
full of personal init files that "proudly" do that, and forums like
Reddit are full of such advice to every newbie who asks about
configuring their Emacs.  It is hard to be enthusiastic about making
these features more modern when the community seems to be divided on
whether they should at all be present.  IMO, we should first get our
act together and decide whether these features are important, and then
speak up according to those decisions when we see advice to the
contrary.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

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

On 16/04/2020 01.28, Eli Zaretskii wrote:
>> From: Richard Stallman <rms@gnu.org>
>> Date: Wed, 15 Apr 2020 22:30:20 -0400
>> Cc: emacs-devel@gnu.org, ndame@protonmail.com
>>
>> Another question about them: are they among the segment of users for
>> whom the investment of learning Emacs would pay off?
> 
> I don't really know the answer, but I'd like to remind all of us that
> there's a lot of "propaganda" out there telling everyone to turn off
> GUI features such as the menu bar and the tool bar.  The network is
> full of personal init files that "proudly" do that, and forums like
> Reddit are full of such advice to every newbie who asks about
> configuring their Emacs.  It is hard to be enthusiastic about making
> these features more modern when the community seems to be divided on
> whether they should at all be present.  IMO, we should first get our
> act together and decide whether these features are important, and then
> speak up according to those decisions when we see advice to the
> contrary.

That's a great point.  My personal config has the tool bar turned off.  Part of the reason is that with my desktop configuration (using a dark theme) the icons are unreadable (dark grey on a dark background, see attached screenshot), and part of the reason is that I didn't like the look of the icons in some of the (few) modes that use the tool-bar (e.g. in message-mode).  (Also, I seem to have a bug with the tool-bar: when I hover over the first two buttons it doesn't show a tooltip, but if I click on of them and close the file-selection dialog before hovering over the button again I do see a tooltip).

On the other hand, I have written some modes that override the user configuration and re-enable to tool-bar with mode-specific functions, and I haven't received complaints (see e.g. the attached screenshots).

Clément.

[-- Attachment #2: emacs-Q.png --]
[-- Type: image/png, Size: 24493 bytes --]

[-- Attachment #3: fstar-toolbar.png --]
[-- Type: image/png, Size: 18273 bytes --]

Re: "Why is emacs so square?"

[Marcin Borkowski]

On 2020-04-16, at 18:27, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:

> My personal config has the tool bar turned off.

Same here, though I would not force that to new users.  (Recommend,
perhaps.)

Interestingly, I am almost sure that the toolbar was turned off by
default when I started using Emacs (v18 or 19, I don't remember).  IIRC,
when after some upgrade the toolbar appeared, I turned it off at once.
Does that seem possible or is my memory wrong?

OTOH, I learned Emacs by first using the tutorial and then reading most
of the manual, so I probably have a rather atypical history wrt that.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Thu, 16 Apr 2020 20:26:54 +0200
> Cc: emacs-devel@gnu.org
> 
> Interestingly, I am almost sure that the toolbar was turned off by
> default when I started using Emacs (v18 or 19, I don't remember).

Emacs didn't have a tool bar before Emacs 21.1.

RE: "Why is emacs so square?"

[Drew Adams]

> Interestingly, I am almost sure that the toolbar was turned off by
> default when I started using Emacs (v18 or 19, I don't remember).

There was no tool-bar support till Emacs 21.

Re: "Why is emacs so square?"

[Bob Newell]

> I don't really know the answer, but I'd like to remind all of us that
> there's a lot of "propaganda" out there telling everyone to turn off
> GUI features such as the menu bar and the tool bar.  The network is
> full of personal init files that "proudly" do that, and forums like
> Reddit are full of such advice to every newbie who asks about
> configuring their Emacs.

Well, I certainly turn all that stuff off, but I've been using Emacs
for decades, and I'm comfortable enough now (and I also use Helm). In
earlier days I definitely made good use of the toolbar and menus. They
were not especially pretty (that didn't concern me), but they helped
me learn much more quickly.

I would, however, /never/ recommend to a newbie to turn off the menu
bar etc. You should only get to Emacs "minimalism" (a) after a long
enough time to be quite comfortable and (b) if it suits your style of
work.

-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: "Why is emacs so square?"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>                                         IMO, we should first get our
> act together and decide whether these features are important, and then
> speak up according to those decisions when we see advice to the
> contrary.

FWIW, I wrote up a bug report to the `better-defaults' package asking to
please keep them enabled:

https://github.com/technomancy/better-defaults/issues/37

I believe this blanket advice to disable the menu and tool bar should be
similarly discouraged whenever and wherever we can.  (EmacsWiki could be
a good place to start, and maybe some of the other "starter packs".)

Best regards,
Stefan Kangas

RE: "Why is emacs so square?"

[Drew Adams]

> FWIW, I wrote up a bug report to the `better-defaults' package asking
> to please keep [menu-bar and toolbar) enabled:
> 
> https://github.com/technomancy/better-defaults/issues/37
> 
> I believe this blanket advice to disable the menu and tool-bar should
> be similarly discouraged whenever and wherever we can.  (EmacsWiki could
> be a good place to start, and maybe some of the other "starter packs".)

I agree.

But I agree much more strongly wrt menu-bar.

Wrt the Emacs tool-bar, I think (so far) it's
mainly useful for one-off actions (e.g. click
a button to do something - no subsequent
tool-bar interaction).

That is, I'm not sure how often a tool-bar
user clicks tool-bar buttons/icons.  I kinda
doubt that someone does click-click-click on
icons.  I think it's more likely that a user
uses a particular icon fairly often, as a
shortcut to using a menu, than it is that a
user interacts frequently with multiple icons
on the tool-bar.  (I could be wrong.)

As a result of this assumption, I provide
library `tool-bar+.el', which lets you hide
the tool-bar, replacing it by just one menu-bar
pseudo-menu, `Buttons'.  Clicking that pops
up the tool-bar for the duration of one
interaction.  This is available using minor
mode `tool-bar-pop-up-mode'.

https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus

(The same library offers an alternative,
minor mode `tool-bar-here-mode', which is the
same as the global `tool-bar-mode' except that
it affects only the current frame -- it saves
screen real estate on frames other than those
with a tool-bar.)

I think it would make sense for Emacs default
behavior to be similar to that you get by
turning on `tool-bar-pop-up-mode'.  Users would
soon enough discover `Buttons'.

One useful thing that could be added and might
be useful, which I haven't done, would be to
provide a button in every tool-bar, which
toggles the mode, e.g., turns it off, so the
tool-bar is shown by default, or turns it on,
so it is hidden by default and replaced by
pseudo-menu `Buttons'.

Re: "Why is emacs so square?"

[Jorge Javier Araya Navarro]

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

El mié, 15-04-2020 a las 06:39 +0200, Stefan Kangas escribió:
> Richard Stallman <rms@gnu.org> writes:
> 
> > Perhaps we should implement a mode that puts cosmetics on Emacs
> 
> Is there any reason not to improve the default look?
> 
> > so it will appeal to those who judge by the surface of things.
> 
> I think it's unfortunate if we assume that this is all bells and
> whistles.  Graphical design elements can also improve usability.
> 
> I also don't know that it's helpful to assume that the rest of the
> world will take the enlightened stance.  For example, I've always
> assumed that many people use Sublime Text not due to any serious
> feature comparison with Emacs, but because they like its "sleek
> look".
> I don't suggest that we should imitate proprietary junk editor <foo>,
> but we should realize that these things are not wholly unimportant.
> 
> Best regards,
> Stefan Kangas
> 

Allow me to interject: how modern does my Emacs looks (see attach)?
that is just using some packages available at MELPA (sad, I know;
ideally such cosmetic stuff should be available in ELPA and/or be ship
with new versions of Emacs and turned on by default).

[-- Attachment #2: Captura de pantalla de 2020-04-15 23-00-35.png --]
[-- Type: image/png, Size: 115021 bytes --]

Re: "Why is emacs so square?"

[Juri Linkov]

>> Perhaps we should implement a mode that puts cosmetics on Emacs
>
> Is there any reason not to improve the default look?

No reason indeed.  I started to implement rounded corners for tabs
by adding a new :style to :box face attribute with drawings implemented
like in x_draw_relief_rect but had no time to finish before the
emacs-27 pretest.  But it looks like a wrong approach anyway.

But when someone will properly implement rounded corners for buttons
they could be used for tabs as well.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 14 Apr 2020 23:00:48 -0400
> Cc: emacs-devel@gnu.org
> 
> Perhaps we should implement a mode that puts cosmetics on Emacs
> so it will appeal to those who judge by the surface of things.

I think if we had the code for making the corners round, we'd use it
more or less unconditionally.  But we don't have such code, AFAIK, so
patches to add such capabilities to Emacs are most welcome.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 15.04.2020 09:27, Eli Zaretskii wrote:
> I think if we had the code for making the corners round, we'd use it
> more or less unconditionally.  But we don't have such code, AFAIK, so
> patches to add such capabilities to Emacs are most welcome.

I think the difficulty here is to look "contemporary" and yet fit every 
platform Emacs is run on. Button widgets look different on each. Even 
between GUI toolkits. And change between releases.

The other option, of course, is to look both modern and unique, but it's 
a harder proposition, especially without a graphical designer on the 
team. And this stuff gets outdated quickly.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, ndame@protonmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 15 Apr 2020 17:17:31 +0300
> 
> On 15.04.2020 09:27, Eli Zaretskii wrote:
> > I think if we had the code for making the corners round, we'd use it
> > more or less unconditionally.  But we don't have such code, AFAIK, so
> > patches to add such capabilities to Emacs are most welcome.
> 
> I think the difficulty here is to look "contemporary" and yet fit every 
> platform Emacs is run on. Button widgets look different on each. Even 
> between GUI toolkits. And change between releases.

There are only 2 variants: native buttons (provided by some toolkit)
or the ones we draw ourselves.  And there's no requirement that they
all look the same, I think: they should have the look-and-feel of the
toolkit being used.

> The other option, of course, is to look both modern and unique, but it's 
> a harder proposition, especially without a graphical designer on the 
> team. And this stuff gets outdated quickly.

I think "modern and unique" is a contradiction of terms nowadays ;-)

Re: "Why is emacs so square?"

[Ulrich Mueller]

>>>>> On Wed, 15 Apr 2020, Eli Zaretskii wrote:

>> I think the difficulty here is to look "contemporary" and yet fit
>> every platform Emacs is run on. Button widgets look different on
>> each. Even between GUI toolkits. And change between releases.

> There are only 2 variants: native buttons (provided by some toolkit)
> or the ones we draw ourselves.  And there's no requirement that they
> all look the same, I think: they should have the look-and-feel of the
> toolkit being used.

Exactly, and I presume it would be somewhat hard to emulate the GTK+
look under Athena/Lucid or Motif. Also, what problem would it solve?

>> The other option, of course, is to look both modern and unique, but it's 
>> a harder proposition, especially without a graphical designer on the 
>> team. And this stuff gets outdated quickly.

> I think "modern and unique" is a contradiction of terms nowadays ;-)

"Modern" mostly means that everything looks like half-sucked candy.
Please resist that temptation. :-)

Re: "Why is emacs so square?"

[Alex Bennée]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Wed, 15 Apr 2020, Eli Zaretskii wrote:
>
>>> I think the difficulty here is to look "contemporary" and yet fit
>>> every platform Emacs is run on. Button widgets look different on
>>> each. Even between GUI toolkits. And change between releases.
>
>> There are only 2 variants: native buttons (provided by some toolkit)
>> or the ones we draw ourselves.  And there's no requirement that they
>> all look the same, I think: they should have the look-and-feel of the
>> toolkit being used.
>
> Exactly, and I presume it would be somewhat hard to emulate the GTK+
> look under Athena/Lucid or Motif. Also, what problem would it solve?

Surely unifying under a single cross-platform toolkit like GTK+ would
avoid having this complexity. I still run lucid because there is a long
term bug in the GTK engine which I don't understand but gets loudly
reported whenever you run it. I'm not sure if this is down to the
toolkit or the thunking Emacs has to do to have a common command loop
shared between it's GUI and terminal invocations?

>>> The other option, of course, is to look both modern and unique, but it's 
>>> a harder proposition, especially without a graphical designer on the 
>>> team. And this stuff gets outdated quickly.
>
>> I think "modern and unique" is a contradiction of terms nowadays ;-)
>
> "Modern" mostly means that everything looks like half-sucked candy.
> Please resist that temptation. :-)

There is a danger in assuming everybody wants their experience to be
like ours. My personal config may be fairly austere and minimalist but
we should aim for the out-of-the-box experience to look nice and be
intuitive for new users. I've been thinking about text editors for my
children to use as they graduate from point and click programming to
proper text and even I'm not sure I want their first experience to be
Emacs.

-- 
Alex Bennée

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Alex Bennée <alex.bennee@linaro.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Thu, 16 Apr 2020 11:14:21 +0100
> 
> > Exactly, and I presume it would be somewhat hard to emulate the GTK+
> > look under Athena/Lucid or Motif. Also, what problem would it solve?
> 
> Surely unifying under a single cross-platform toolkit like GTK+ would
> avoid having this complexity.

GTK+ is not cross-platform, it works only on some of the platforms we
support (and is not an easy toolkit to work with, based on our
experience).

> I still run lucid because there is a long term bug in the GTK engine
> which I don't understand but gets loudly reported whenever you run
> it. I'm not sure if this is down to the toolkit

This is because GTK+ has a bug that AFAIR they don't intend to fix
because they don't consider our use of GTK+ important enough (or
correct, for that matter).

> or the thunking Emacs has to do to have a common command loop shared
> between it's GUI and terminal invocations?

Not sure what thunking did you have in mind.  The handling of input in
Emacs should consider both GUI and TTY inputs, since otherwise you
will be unable to have both GUI and TTY frames in the same session,
and the likes of "emacsclient -t" won't work.

Re: "Why is emacs so square?"

[chad]

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

On Thu, Apr 16, 2020 at 3:22 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Alex Bennée <alex.bennee@linaro.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > Date: Thu, 16 Apr 2020 11:14:21 +0100
> >
> > Surely unifying under a single cross-platform toolkit like GTK+ would
> > avoid having this complexity.
>
> GTK+ is not cross-platform, it works only on some of the platforms we
> support (and is not an easy toolkit to work with, based on our
> experience).
>

I wrote a longer post about this topic on the emacs reddit recently, but a
short summary would be: What Eli said, plus some. There is no good
cross-platform GUI toolkit (free or otherwise), and the closest the
software world has today is Electron (which still doesn't cover everything
emacs supports). I realize that there are some partial solutions that
advertise themselves as cross-platform, but if you poke at them with a
moderately keen eye, they collapse quickly. As a practical matter, this is
a big reason that some of emacs' biggest competitors these days are based
on Electron (VS Code and Atom) and Java.

~Chad

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

Re: "Why is emacs so square?"

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

  > software world has today is Electron (which still doesn't cover everything
  > emacs supports).

Is Electron free software?  If so, what is its license,
and what does Emacs do that Electron does not support?
(If there are lots of things, a few important ones would
be enough of an answer.)


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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, ulm@gentoo.org, alex.bennee@linaro.org,
> 	emacs-devel@gnu.org
> Date: Fri, 17 Apr 2020 22:03:04 -0400
> 
> Is Electron free software?  If so, what is its license,

Its license is MIT, see below.

  Copyright (c) 2013-2020 GitHub Inc.

  Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
  "Software"), to deal in the Software without restriction, including
  without limitation the rights to use, copy, modify, merge, publish,
  distribute, sublicense, and/or sell copies of the Software, and to
  permit persons to whom the Software is furnished to do so, subject to
  the following conditions:

  The above copyright notice and this permission notice shall be
  included in all copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
  LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
  OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
  WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Re: "Why is emacs so square?"

[chad]

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

As Eli said, Electron is covered by an MIT license. It describes itself
with this sentence:

  Build cross-platform desktop apps with JavaScript, HTML, and CSS.

It accomplishes this by uses Node.js, a JavaScript runtime built on the V8
javascript engine of Chrome. Each Electron app comes with its own
integrated copy of Chromium (the "free" parts of Google's Chrome web
browser, released under a combination of 3-clause BSD, MIT, [L]GPL, and
MS's Shared Source licenses). Without intensional malice, I'd call it a
Frankenstein's monster of both code and license.

Its major features are (in my personal opinion): Google invests effort into
making it function well across major platforms, it's "free enough" that it
can be used by various open, free, and commercial projects, and it lets
people make "desktop apps" using the widely-known web stack of JavaScript,
HTML, and CSS. It can use native code via Node's analog of an FFI. This
combination is so widely spread and optimized at this point that it's
possible to get decent performance alongside gui, threaded, network, etc.
code. It also has a reputation for being fairly bloated, in large part
because each Electron app brings its own copy of chromium, V8, node, etc.
Similarly, Electron apps are rarely well-integrated into a particular OS,
since they're mostly WWW technology; whether this bothers users or not is
currently a shifting topic, as ever more new users are used to using
web-based tech for much of their computer needs.

I hope that helps,
~Chad


On Fri, Apr 17, 2020 at 7:03 PM Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > software world has today is Electron (which still doesn't cover
> everything
>   > emacs supports).
>
> Is Electron free software?  If so, what is its license,
> and what does Emacs do that Electron does not support?
> (If there are lots of things, a few important ones would
> be enough of an answer.)
>
>
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>

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

Re: "Why is emacs so square?"

[Po Lu]

chad <yandros@gmail.com> writes:

> As Eli said, Electron is covered by an MIT license. It describes itself with this sentence:
>
>   Build cross-platform desktop apps with JavaScript, HTML, and CSS.
>
> It accomplishes this by uses Node.js, a JavaScript runtime built on
> the V8 javascript engine of Chrome. Each Electron app comes with its
> own integrated copy of Chromium (the "free" parts of Google's Chrome
> web browser, released under a combination of 3-clause
> BSD, MIT, [L]GPL, and MS's Shared Source licenses). Without
> intensional malice, I'd call it a Frankenstein's monster of both code
> and license.
>
> Its major features are (in my personal opinion): Google invests effort
> into making it function well across major platforms, it's "free
> enough" that it can be used by various open, free, and commercial
> projects, and it lets people make "desktop apps" using the
> widely-known web stack of JavaScript, HTML, and CSS. It can use native code via
> Node's analog of an FFI. This combination is so widely spread and
> optimized at this point that it's possible to get decent performance
> alongside gui, threaded, network, etc. code. It also has a reputation
> for being fairly bloated, in large part because each Electron app
> brings its own copy of chromium, V8, node, etc. Similarly, Electron
> apps are rarely well-integrated into a particular OS, since they're
> mostly WWW technology; whether this bothers users or not is currently
> a shifting topic, as ever more new users are used to using web-based
> tech for much of their computer needs.

Electron has freedom issues.  (https://labs.parabola.nu/issues/1167)

Re: "Why is emacs so square?"

[Po Lu]

> Electron has freedom issues.  (https://labs.parabola.nu/issues/1167)

Some more relevant links:
https://www.mail-archive.com/gnu-linux-libre@nongnu.org/msg02199.html
https://bugs.chromium.org/p/chromium/issues/detail?id=28291
https://lists.gnu.org/archive/html/directory-discuss/2017-12/msg00008.html

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 15.04.2020 17:31, Eli Zaretskii wrote:

>> I think the difficulty here is to look "contemporary" and yet fit every
>> platform Emacs is run on. Button widgets look different on each. Even
>> between GUI toolkits. And change between releases.
> 
> There are only 2 variants: native buttons (provided by some toolkit)
> or the ones we draw ourselves.  And there's no requirement that they
> all look the same, I think: they should have the look-and-feel of the
> toolkit being used.

These are implementation options. But either the "ones we draw 
ourselves" are designed to fit each platform, or they looks the same 
across platforms, with our personal look.

The latter option is sometimes taken by professional applications in 
which the user spends most of their time (e.g. Blender, or at least some 
of it earlier versions that I've tried).

>> The other option, of course, is to look both modern and unique, but it's
>> a harder proposition, especially without a graphical designer on the
>> team. And this stuff gets outdated quickly.
> 
> I think "modern and unique" is a contradiction of terms nowadays ;-)

In principle, I disagree. But it's difficult, and it's a balancing act, 
of course, between having them look distinct and interesting, but still 
familiar enough, and not too "tacky" (meaning, a design too exotic can 
become an eyesore after a while). It's a problem that bigger companies 
put whole design departments on.

Re: "Why is emacs so square?"

[chad]

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

For the original poster, because they might be used to running primarily a
distribution-installed version of emacs: the code for unix-based GUIs has
supported a variety of these sorts of elements for a very long time,
depending (currently) on whether you build emacs with the Athena, Lucid,
Motif, Athena3D, or gtk[,2,3] toolkits. Under macOS, one has the ns and mac
ports, and under MS Windows, it uses the local gui toolkit (which I
believe is the core W32 look and feel, not the frequently-shifting WPF,
Windows Forms, Metro, UWP, etc. standards).  Even within these systems,
there are options inside emacs for giving buttons a 3D look or not, and
there are many packages that add icons to emacs' display (via fonts, as far
as I can tell) that can 'spiffy up' emacs considerably.

It would probably be helpful for emacs' adoption if some of these gui
enhancements could be added to emacs and/or ELPA more directly. To be
specific, it would perhaps be helpful for emacs new-user adoption if people
didn't feel the need to adopt a large integrated package like Spacemacs or
DOOM emacs just to get graphical niceties -- not because those bundles are
bad, but because they add a *lot* more than just the gui enhancements. The
past couple years has seen a bit of an explosion of packages like
better-defaults or "starter kits" that aim to improve the new-user
experience without such a large overhead, but those still require getting
emacs from somewhere other than GNU or the standard distrubutions, which is
an extra hurdle.

I would be happy to help with such an effort, but I'm unsure what sorts of
changes would be acceptible to "core emacs", and I don't personally have
anything major to add to the existing set of third-party starter kits or
mega-bundles. If someone here had a clearer idea, that would be helpful.
Maybe the first step is to try to get all-the-icons (
https://github.com/domtronn/all-the-icons.el) or an analogous package
included in emacs?

Hope that helps! Thanks,
~Chad

On Wed, Apr 15, 2020 at 10:16 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 15.04.2020 17:31, Eli Zaretskii wrote:
>
> >> I think the difficulty here is to look "contemporary" and yet fit every
> >> platform Emacs is run on. Button widgets look different on each. Even
> >> between GUI toolkits. And change between releases.
> >
> > There are only 2 variants: native buttons (provided by some toolkit)
> > or the ones we draw ourselves.  And there's no requirement that they
> > all look the same, I think: they should have the look-and-feel of the
> > toolkit being used.
>
> These are implementation options. But either the "ones we draw
> ourselves" are designed to fit each platform, or they looks the same
> across platforms, with our personal look.
>
> The latter option is sometimes taken by professional applications in
> which the user spends most of their time (e.g. Blender, or at least some
> of it earlier versions that I've tried).
>
> >> The other option, of course, is to look both modern and unique, but it's
> >> a harder proposition, especially without a graphical designer on the
> >> team. And this stuff gets outdated quickly.
> >
> > I think "modern and unique" is a contradiction of terms nowadays ;-)
>
> In principle, I disagree. But it's difficult, and it's a balancing act,
> of course, between having them look distinct and interesting, but still
> familiar enough, and not too "tacky" (meaning, a design too exotic can
> become an eyesore after a while). It's a problem that bigger companies
> put whole design departments on.
>
>

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

Re: "Why is emacs so square?"

[ndame]

> For the original poster, because they might be used to running
> primarily a distribution-installed version of emacs: the code for
> unix-based GUIs has supported a variety of these sorts of elements
> for a very long time, depending (currently) on whether you build
> emacs with the Athena, Lucid, Motif, Athena3D, or gtk[,2,3]
> toolkits. Under macOS, one has the ns and mac ports, and under MS
> Windows, it uses the local gui toolkit (which I believe is the core
> W32 look and feel, not the frequently-shifting WPF, Windows Forms,
> Metro, UWP, etc. standards). 


I use the official windows build and it looks like this which is
definitely not how buttons look in windows dialogs:

https://i.imgur.com/TjaMGwF.png

The native buttons don't have a thick shadow like this.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Wed, 15 Apr 2020 20:44:16 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Eli Zaretskii <eliz@gnu.org>,
>  Richard Stallman <rms@gnu.org>, EMACS development team <emacs-devel@gnu.org>
> 
> I use the official windows build and it looks like this which is
> definitely not how buttons look in windows dialogs:
> 
> https://i.imgur.com/TjaMGwF.png
> 
> The native buttons don't have a thick shadow like this.

We don't use the native buttons on MS-Windows.  The only native
widgets used on MS-Windows (AFAIR) are the menu bar and the scroll
bars.

Re: "Why is emacs so square?"

[ndame]

>
> We don't use the native buttons on MS-Windows. The only native
> widgets used on MS-Windows (AFAIR) are the menu bar and the scroll
> bars.

Interesting. I sort of assumed Emacs looks the same everywhere and
thought all emacs users saw these old fashioned buttons if they
open up Customize which I see on Windows.

But if emacs uses native buttons elsewhere then it means Emacs
can look much better on other platforms, at least as far as
we consider GUI widgets.

Wouldn't it make sense to use native controls on every graphical
platform?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Thu, 16 Apr 2020 06:00:33 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "yandros@gmail.com" <yandros@gmail.com>, "dgutov@yandex.ru" <dgutov@yandex.ru>, "rms@gnu.org" <rms@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> 
> >
> > We don't use the native buttons on MS-Windows. The only native
> > widgets used on MS-Windows (AFAIR) are the menu bar and the scroll
> > bars.
> 
> Interesting. I sort of assumed Emacs looks the same everywhere and
> thought all emacs users saw these old fashioned buttons if they
> open up Customize which I see on Windows.

Emacs's look-and-feel varies depending on the toolkit used to build
it.  So it cannot look the same everywhere, not in every aspect of the
GUI decorations and widgets.

> But if emacs uses native buttons elsewhere then it means Emacs
> can look much better on other platforms, at least as far as
> we consider GUI widgets.

I think you are generalizing too much here.  We don't use toolkit
widgets for every element of our GUI.  So some "buttons" are native
(for example, the tool bar of the GTK+ build), while others are not.
Which toolkit build uses what widgets where depends on what the people
who wrote the related code did, not some policy decision.  And
sometimes we even have options to let users choose between native and
Emacs-implemented GUI elements, like the x-gtk-use-system-tooltips in
the GTK builds.

> Wouldn't it make sense to use native controls on every graphical
> platform?

That has advantages, of course, but also some disadvantages.
Complexity of code is one of the disadvantages, because some widgets
of some toolkits require special code (like separate input loops) to
be able to use them, or because they have some limitations (e.g., GTK
tooltips cannot display images, at least the way we invoke those
tooltips.

Re: "Why is emacs so square?"

[ndame]

On Thursday, April 16, 2020 4:26 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I think you are generalizing too much here. We don't use toolkit
> widgets for every element of our GUI. So some "buttons" are native
> (for example, the tool bar of the GTK+ build), while others are not.

I thought Customize buttons are native on some platforms, but I checked,
and now I see they are just faces.

It could improve appearance quite a lot if someone with a feel for graphical
design took a look at faces and created some more modern looking defaults.

Re: "Why is emacs so square?"

[ndame]

>
> It could improve appearance quite a lot if someone with a feel for graphical
> design took a look at faces and created some more modern looking defaults.

Though, of course, there is only so much you can do with colors to improve the
graphical appearance.

E.g. checking the GTK buttons they apparently have some small border and,
of course, slightly rounded corners:

https://i.stack.imgur.com/9PLof.png

Re: "Why is emacs so square?"

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

  > It could improve appearance quite a lot if someone with a feel for graphical
  > design took a look at faces and created some more modern looking defaults.

It was very hard to work out a set of default faces that worked
reasonably.  We had to make change after change till everyone
was happy with it.

I think that the help of a graphics UI designer could enable us to
make an improvement _if_ perse is capable of working within the
constraints that we face.

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

Re: "Why is emacs so square?"

[ndame]

>
> some "buttons" are native
> (for example, the tool bar of the GTK+ build),

Just saw on reddit that a user posted a screenshot of an emacs
toolbar with really sad looking icons at the end:

https://i.imgur.com/6sIHOGt.png

They reportedly appear when you invoke M-x report-emacs-bug

I don't know what's going on here, but AFAIK there are
GPLd iconsets for all kind of icons.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Thu, 16 Apr 2020 19:14:27 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "yandros@gmail.com" <yandros@gmail.com>, "dgutov@yandex.ru" <dgutov@yandex.ru>, "rms@gnu.org" <rms@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> Just saw on reddit that a user posted a screenshot of an emacs
> toolbar with really sad looking icons at the end:
> 
> https://i.imgur.com/6sIHOGt.png
> 
> They reportedly appear when you invoke M-x report-emacs-bug
> 
> I don't know what's going on here, but AFAIK there are
> GPLd iconsets for all kind of icons.

Feel free to point us to GPLed icons that can be incorporated in
Emacs.  At the time, the situation was nowhere as easy as you imply,
but maybe things have changed since then.

Re: "Why is emacs so square?"

[ndame]

>
> Feel free to point us to GPLed icons that can be incorporated in
> Emacs. At the time, the situation was nowhere as easy as you imply,
> but maybe things have changed since then.

Aren't the icons used by GTK/Gnome GPL licensed? I assumed they
were if GTK/Gnome uses them.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 16.04.2020 22:26, Eli Zaretskii wrote:
> Feel free to point us to GPLed icons that can be incorporated in
> Emacs.  At the time, the situation was nowhere as easy as you imply,
> but maybe things have changed since then.

Are these okay?

https://commons.wikimedia.org/wiki/GNOME_Desktop_icons

And an older set: https://commons.wikimedia.org/wiki/Tango_icons 
(they're supposedly released under Creative Commons).

Re: "Why is emacs so square?"

[ndame]

>
> Are these okay?
>
> https://commons.wikimedia.org/wiki/GNOME_Desktop_icons
>


There are also the KDE icon set, though it's LGPL 3 licensed.
I don't know if it's OK in Emacs:

https://github.com/KDE/oxygen-icons

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Thu, 16 Apr 2020 20:30:36 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, "yandros@gmail.com" <yandros@gmail.com>, "rms@gnu.org" <rms@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > Are these okay?
> >
> > https://commons.wikimedia.org/wiki/GNOME_Desktop_icons
> 
> There are also the KDE icon set, though it's LGPL 3 licensed.
> I don't know if it's OK in Emacs:
> 
> https://github.com/KDE/oxygen-icons

Someone™ needs to invest the time and effort to figure out the legal
issues, find the icons that we want out of those which are legally
fit, and post the resulting information.  We did that process at the
time (AFAIR, quite a few of our icons come from Gnome/GTK), and it
wasn't easy.

Alternatively, someone could create our own icons, in which case they
could be even prettier than the ones pointed out here.

In any case, this is a non-trivial job, and volunteers are most
welcome to do it.  I don't think anyone is happy about the icons shown
on the tool bar by Message mode; the only reason we use them is that
we couldn't find better ones that are free and suitable for inclusion
in Emacs.

Thanks.

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 17, 2020, at 16:06, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> In any case, this is a non-trivial job, and volunteers are most
> welcome to do it.  I don't think anyone is happy about the icons shown
> on the tool bar by Message mode; the only reason we use them is that
> we couldn't find better ones that are free and suitable for inclusion
> in Emacs.

What is the criteria for "suitable" ? Is that an esthetical one ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Fri, 17 Apr 2020 16:28:33 +0900
> 
> > On Apr 17, 2020, at 16:06, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > In any case, this is a non-trivial job, and volunteers are most
> > welcome to do it.  I don't think anyone is happy about the icons shown
> > on the tool bar by Message mode; the only reason we use them is that
> > we couldn't find better ones that are free and suitable for inclusion
> > in Emacs.
> 
> What is the criteria for "suitable" ? Is that an esthetical one ?

"Suitable" in all the senses mentioned in this discussion.  Including,
but not limited to, aesthetics.

Re: "Why is emacs so square?"

[Dmitry Gutov]

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

On 17.04.2020 13:00, Eli Zaretskii wrote:
>> From: Jean-Christophe Helary<jean.christophe.helary@traduction-libre.org>
>> Date: Fri, 17 Apr 2020 16:28:33 +0900
>>
>>> On Apr 17, 2020, at 16:06, Eli Zaretskii<eliz@gnu.org>  wrote:
>>>
>>> In any case, this is a non-trivial job, and volunteers are most
>>> welcome to do it.  I don't think anyone is happy about the icons shown
>>> on the tool bar by Message mode; the only reason we use them is that
>>> we couldn't find better ones that are free and suitable for inclusion
>>> in Emacs.
>> What is the criteria for "suitable" ? Is that an esthetical one ?
> "Suitable" in all the senses mentioned in this discussion.  Including,
> but not limited to, aesthetics.

I have a suggestion that might circumvent this whole discussion.

Just now, I turned on the toolbar and entered bug reporting mode with 
'M-x report-emacs-bug'. I am using a GNOME theme specially made for Ubuntu.

The attached picture shows a toolbar with an assortment of icons where 
about half obey the current theme and the rest don't. I also tried 
switching between icons themes to confirm this.

The icons to the left of "Send Message", as well as the "Kill Message" 
icon, change together with the themes. The red round thingy with an "x" 
changes only with some themes, but not with the rest. Perhaps that means 
that the icon with that name/identifier is themed more rarely. But it's 
still somewhat standard.

The rest of the icons ("Send Message", "Attach File" and the rest after 
it) never follow the theme.

Perhaps the solution, at least for the GTK builds, would be to find the 
standard icons (more concretely, icon names) that can be used for these 
buttons, instead of picking among the icon sets. The latter should be 
the user's choice, after all.

[-- Attachment #2: Screenshot from 2020-04-22 02-44-26.png --]
[-- Type: image/png, Size: 94693 bytes --]

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 02:54:13 +0300
> 
> Just now, I turned on the toolbar and entered bug reporting mode with 
> 'M-x report-emacs-bug'. I am using a GNOME theme specially made for Ubuntu.

I don't think I follow.  Where can I find this "GNOME theme"?  It's
not part of the Emacs release tarball, is it?

> The attached picture shows a toolbar with an assortment of icons where 
> about half obey the current theme and the rest don't. I also tried 
> switching between icons themes to confirm this.
> 
> The icons to the left of "Send Message", as well as the "Kill Message" 
> icon, change together with the themes. The red round thingy with an "x" 
> changes only with some themes, but not with the rest. Perhaps that means 
> that the icon with that name/identifier is themed more rarely. But it's 
> still somewhat standard.
> 
> The rest of the icons ("Send Message", "Attach File" and the rest after 
> it) never follow the theme.

What exactly do you mean by "icons follow the theme"? how does a theme
affect icons?

> Perhaps the solution, at least for the GTK builds, would be to find the 
> standard icons (more concretely, icon names) that can be used for these 
> buttons

AFAIR, last time we made such an effort, we indeed took icons from GTK
or GNOME or from some similar collection.  But that was a long time
ago, and in particular the two rightmost icons you see in Message mode
were not part of that set, they were added by someone later.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 22/04/2020 09.21, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Wed, 22 Apr 2020 02:54:13 +0300
>>
>> Just now, I turned on the toolbar and entered bug reporting mode with 
>> 'M-x report-emacs-bug'. I am using a GNOME theme specially made for Ubuntu.
> 
> I don't think I follow.  Where can I find this "GNOME theme"?  It's
> not part of the Emacs release tarball, is it?

It's shipped by GNU/Linux distributions, typically.

> What exactly do you mean by "icons follow the theme"? how does a theme
> affect icons?

In GTK builds (the default in Debian, and probably others), the toolbar uses icons from the current GTK icon theme.  I believe this is done in update_frame_tool_bar in gtkutil.c.

>> Perhaps the solution, at least for the GTK builds, would be to find the 
>> standard icons (more concretely, icon names) that can be used for these 
>> buttons

> AFAIR, last time we made such an effort, we indeed took icons from GTK
> or GNOME or from some similar collection.  But that was a long time
> ago, and in particular the two rightmost icons you see in Message mode
> were not part of that set, they were added by someone later.

It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).

Clément.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 22 Apr 2020 10:05:15 -0400
> 
> > I don't think I follow.  Where can I find this "GNOME theme"?  It's
> > not part of the Emacs release tarball, is it?
> 
> It's shipped by GNU/Linux distributions, typically.

Any chance of getting a URL that I could explore?

> > What exactly do you mean by "icons follow the theme"? how does a theme
> > affect icons?
> 
> In GTK builds (the default in Debian, and probably others), the toolbar uses icons from the current GTK icon theme.  I believe this is done in update_frame_tool_bar in gtkutil.c.

Then I don't understand the complaint.  The icons that don't change
are our private icons that aren't taken from GTK.  So how can they
"follow the theme", if they are absent there?

> >> Perhaps the solution, at least for the GTK builds, would be to find the 
> >> standard icons (more concretely, icon names) that can be used for these 
> >> buttons
> 
> > AFAIR, last time we made such an effort, we indeed took icons from GTK
> > or GNOME or from some similar collection.  But that was a long time
> > ago, and in particular the two rightmost icons you see in Message mode
> > were not part of that set, they were added by someone later.
> 
> It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).

That would only help GTK users.  I thought we wanted to improve the
Emacs appearance on more than just one toolkit, especially since that
toolkit is troubled and many users avoid building with it for that
reason.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 22/04/2020 10.29, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 22 Apr 2020 10:05:15 -0400
>>
>>> I don't think I follow.  Where can I find this "GNOME theme"?  It's
>>> not part of the Emacs release tarball, is it?
>>
>> It's shipped by GNU/Linux distributions, typically.
> 
> Any chance of getting a URL that I could explore?

Yes, of course. Here is the theme used on my machine, for example: https://github.com/linuxmint/mint-y-icons
strace-ing `emacs -Q' on my machine suggests that it loads the following icons for the default tool-bar:

  13718:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/document-new.svg", O_RDONLY) = 15
  13728:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/document-open.svg", O_RDONLY) = 15
  13747:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/window-close.svg", O_RDONLY) = 15
  13752:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/document-save.svg", O_RDONLY) = 15
  13757:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-undo.svg", O_RDONLY) = 15
  13762:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-cut.svg", O_RDONLY) = 15
  13767:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-copy.svg", O_RDONLY) = 15
  13772:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-paste.svg", O_RDONLY) = 15
  13777:openat(AT_FDCWD, "/usr/share/icons/Mint-Y/actions/22/edit-find.svg", O_RDONLY) = 15

The icon naming spec is here: https://developer.gnome.org/icon-naming-spec/

>>> What exactly do you mean by "icons follow the theme"? how does a theme
>>> affect icons?
>>
>> In GTK builds (the default in Debian, and probably others), the toolbar uses icons from the current GTK icon theme.  I believe this is done in update_frame_tool_bar in gtkutil.c.
> 
> Then I don't understand the complaint.  The icons that don't change
> are our private icons that aren't taken from GTK.  So how can they
> "follow the theme", if they are absent there?

IIUC, the claim is that there (likely) are standard icons close to the ones we use, and that using the corresponding icon names would give us good-looking icons by default on Gtk.
Concretely, for the actions shown in the message toolbar, this would be these:

mail-attachment 
document-send or mail-send
tools-check-spelling
mail-mark-important

The spec doesn't seem to have actions for marking an email unimportant or requesting an email receipt.

>>>> Perhaps the solution, at least for the GTK builds, would be to find the 
>>>> standard icons (more concretely, icon names) that can be used for these 
>>>> buttons
>>
>>> AFAIR, last time we made such an effort, we indeed took icons from GTK
>>> or GNOME or from some similar collection.  But that was a long time
>>> ago, and in particular the two rightmost icons you see in Message mode
>>> were not part of that set, they were added by someone later.
>>
>> It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).
> 
> That would only help GTK users.  I thought we wanted to improve the
> Emacs appearance on more than just one toolkit, especially since that
> toolkit is troubled and many users avoid building with it for that
> reason.

Sure, importing icons is also a good idea.  But the OP was making the point that we can easily improve the situation without bikeshedding a specific icon choice by respecting existing user themes.

Clément.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 17:29, Eli Zaretskii wrote:
>> It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).
> That would only help GTK users.

Yes, indeed. But it's still probably the most popular toolkit among 
GNU/Linux users.

> I thought we wanted to improve the
> Emacs appearance on more than just one toolkit,

On e.g. Lucid all icons come from the same set, at least. We can improve 
them as well (all together), but it's a fairly different task.

Speaking of other platforms, I wonder if Windows and macOS also have 
have standard sets of icons.

It would make our task easier (and the end result more native-looking) 
if we could use a similar approach.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 19:14:01 +0300
> 
> On 22.04.2020 17:29, Eli Zaretskii wrote:
> >> It should be enough to change the name of the icons on the toolbar. No need to take icons from GTK (if that means copying files into the Emacs repo).
> > That would only help GTK users.
> 
> Yes, indeed. But it's still probably the most popular toolkit among 
> GNU/Linux users.

And the icons look the same, no matter what distribution are we
talking about?  Doesn't something depend also on the desktop that's in
use, and perhaps also on the window manager?

> > I thought we wanted to improve the
> > Emacs appearance on more than just one toolkit,
> 
> On e.g. Lucid all icons come from the same set, at least. We can improve 
> them as well (all together), but it's a fairly different task.
> 
> Speaking of other platforms, I wonder if Windows and macOS also have 
> have standard sets of icons.

"Standard" as in "subject to change without notice" each time the
vendor decides to change the look-and-feel (which happens roughly
every 2 to 3 years).  And that's even before we solve the problem of
showing those "standard" icons in Emacs -- e.g., on Windows it is
customary to compile the icons into the binary, something that we
cannot do and then distribute the binary from the GNU FTP site.

> It would make our task easier (and the end result more native-looking) 
> if we could use a similar approach.

I'm not sure I like this direction.  It sounds like the opposite of
having an Emacs that looks more or less the same on all major
platforms.  How will the users (and newbies at that, since we are
talking about them primarily) be able to find their ways in Emacs, if
the icons change with the desktop/platform, and every few years even
on the same platform?  E.g., you buy the Emacs manual printed a year
or 2 ago, but the icons it shows are all different from what's on
display.  I don't even understand how will we be able to show the
icons in our Info manual, if the images don't come with Emacs and are
different on each platform/build.  Do we really want to go in that
direction? just to say we look "modern"?  Something people should
seriously think and make up their minds about before such decisions
are made, I guess.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 22/04/2020 12.55, Eli Zaretskii wrote:
> I'm not sure I like this direction.  It sounds like the opposite of
> having an Emacs that looks more or less the same on all major
> platforms.  How will the users (and newbies at that, since we are
> talking about them primarily) be able to find their ways in Emacs, if
> the icons change with the desktop/platform, and every few years even
> on the same platform?  E.g., you buy the Emacs manual printed a year
> or 2 ago, but the icons it shows are all different from what's on
> display.  I don't even understand how will we be able to show the
> icons in our Info manual, if the images don't come with Emacs and are
> different on each platform/build.  Do we really want to go in that
> direction? just to say we look "modern"?  Something people should
> seriously think and make up their minds about before such decisions
> are made, I guess.

This is a legitimate worry, but you have to balance it against consistency with other applications.  When I change my desktop theme, icons change in most apps, and the same concept gets the same icon in all apps.

Emacs is partly like that, partly not: some icons change and some don't.

We can have a discussion on whether to use a unified icon set on all platforms, but in the meantime making Emacs' behavior consistent would be a plus, and should be an easy change.

Clément.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 19:55, Eli Zaretskii wrote:
> And the icons look the same, no matter what distribution are we
> talking about?  Doesn't something depend also on the desktop that's in
> use, and perhaps also on the window manager?

No, the icons looks different across themes. Hence the whole notion of 
"icon themes". But the set of icon names is fairly stable. This is what 
we'd be relying on.

See x-gtk-stock-map for some more detail.

> I'm not sure I like this direction.  It sounds like the opposite of
> having an Emacs that looks more or less the same on all major
> platforms.

Right. It's already not the case.

> How will the users (and newbies at that, since we are
> talking about them primarily) be able to find their ways in Emacs, if
> the icons change with the desktop/platform, and every few years even
> on the same platform?

People have been doing all right regarding that. At least, I haven't 
seen much criticism of GTK's approach in this regard.

> E.g., you buy the Emacs manual printed a year
> or 2 ago, but the icons it shows are all different from what's on
> display.  I don't even understand how will we be able to show the
> icons in our Info manual, if the images don't come with Emacs and are
> different on each platform/build.

The window looks are different between platforms anyway. As well as such 
fundamental thing as the placement of window's close/maximize/iconize 
buttons.

> Do we really want to go in that
> direction? just to say we look "modern"?

On GTK, we're already there. Since 22.2, apparently. Only we haven't 
been paying attention to keeping this feature in proper maintenance. I'm 
guessing because some of our core developers use other platforms, others 
build with Lucid, and the reset disable the toolbars? But that's not a 
good approach.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 20:06:08 +0300
> 
> On 22.04.2020 19:55, Eli Zaretskii wrote:
> > And the icons look the same, no matter what distribution are we
> > talking about?  Doesn't something depend also on the desktop that's in
> > use, and perhaps also on the window manager?
> 
> No, the icons looks different across themes. Hence the whole notion of 
> "icon themes". But the set of icon names is fairly stable. This is what 
> we'd be relying on.

But a given theme is not available universally, not even with the same
toolkit, I guess?

> > I'm not sure I like this direction.  It sounds like the opposite of
> > having an Emacs that looks more or less the same on all major
> > platforms.
> 
> Right. It's already not the case.

Which is already bad, IMO.  But before we make this a rule rather than
an exception or a historical accident, we should think hard whether we
really want that.  Emacs is special in several ways, and one of them
is its commonality -- you have only ever learn Emacs once, on one
platform.  It's  why I can give advice on Reddit to people that use
platforms I never did.

So this will be a significant change in direction, at least in my
eyes, and the decision should not be made casually, let alone by
default.

> > E.g., you buy the Emacs manual printed a year
> > or 2 ago, but the icons it shows are all different from what's on
> > display.  I don't even understand how will we be able to show the
> > icons in our Info manual, if the images don't come with Emacs and are
> > different on each platform/build.
> 
> The window looks are different between platforms anyway.

No, not really.  They are extremely similar, actually, modulo a few
unimportant bells and whistles.  At least the parts that are relevant
to Emacs are almost identical.

> On GTK, we're already there. Since 22.2, apparently. Only we haven't 
> been paying attention to keeping this feature in proper maintenance.

I'm asking people to think whether we _want_ that.  That we are one
leg there doesn't yet mean we decided to do that consciously.  You are
suggesting to make that a policy, and that's a serious decision, IMO.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 20:19, Eli Zaretskii wrote:
>> No, the icons looks different across themes. Hence the whole notion of
>> "icon themes". But the set of icon names is fairly stable. This is what
>> we'd be relying on.
> But a given theme is not available universally, not even with the same
> toolkit, I guess?

Indeed, it isn't. Although there's always the standard theme for GNOME 
(Adwaita) and the latest Ubuntu theme, we can look at those.

I'm not sure how that's important, though.

>> On GTK, we're already there. Since 22.2, apparently. Only we haven't
>> been paying attention to keeping this feature in proper maintenance.
> I'm asking people to think whether we_want_  that.  That we are one
> leg there doesn't yet mean we decided to do that consciously.  You are
> suggesting to make that a policy, and that's a serious decision, IMO.

First of all, I'm suggesting we fix how the icons look in the GTK build.

Then you are welcome to discuss whether macOS and Windows could use 
something like that. And whether they should. Since you're skeptical of 
this approach from the outset, I'd rather bow out of that discussion.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 20:34:45 +0300
> 
> >> On GTK, we're already there. Since 22.2, apparently. Only we haven't
> >> been paying attention to keeping this feature in proper maintenance.
> > I'm asking people to think whether we_want_  that.  That we are one
> > leg there doesn't yet mean we decided to do that consciously.  You are
> > suggesting to make that a policy, and that's a serious decision, IMO.
> 
> First of all, I'm suggesting we fix how the icons look in the GTK build.

Fixing them by replacing the current icons with prettier ones is okay.
Using the toolkit icons everywhere, as a matter of policy, is a
different matter.

> Then you are welcome to discuss whether macOS and Windows could use 
> something like that. And whether they should. Since you're skeptical of 
> this approach from the outset, I'd rather bow out of that discussion.

Forget MS-Windows and macOS, that's not my worry right now.  IIUC,
your suggestion was to use whatever native icons each toolkit offers
on Posix platforms as well, and it wasn't limited to GTK.  That is the
decision I was talking about.  I myself have no strong opinions on
this, only weak ones.  But no serious decision-making should happen
without a "red team" on board making sure we don't fall victim to
groupthink simply because no one dares to ask a question about the
nature of emperor's clothes.  I tried to present arguments to the
contrary with that in mind, so people could consider both sides.

Re: "Why is emacs so square?"

[chad]

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

On Wed, Apr 22, 2020 at 10:20 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > The window looks are different between platforms anyway.
>
> No, not really.  They are extremely similar, actually, modulo a few
> unimportant bells and whistles.  At least the parts that are relevant
> to Emacs are almost identical.
>

I would agree with this "not really" sentiment, but extend it to include
the differences between icon themes, and where such things work at the OS
level, between OS's. The point of icon themes is to make them all fit
together, and the point of standardized system icons is to have them all
fit together, and the users have shown (for many, many years now) that they
understand this, and can handle the shifts with aplomb. Yes, it is possible
for someone to install a wacky gui-customization pack that changes the
left-arrow into a sausage and the file-folder into a rainbow, but the only
people who do such things are askign for exactly that behavior, and aren't
going to be upset that emacs' toolbar changes along with everything else.

As a practical matter, emacs will need a set of reasonable fallback
defaults, for systems that don't have system-wide settings; we can continue
to use those when the gui environment doesn't help us. The result will
certainly look no worse than the current mixture of icons one can find in
the emacs toolbar. It's very likely that we can improve that set of
fallbacks by adopting a single source for them, such as the GTK or KDE
options mentioned earlier.

A techincal wrinkle here is how those icons are displayed and how they're
stored inside emacs. By way of example, the two KDE icon sets that were
suggested (Breeze and Oxygen) use different file formats: one uses PNG
images; the other SVG. (Oddly, the SVG images are distributed in several
different sizes, which would seem to belie the advantage of using scalable
images in the first place.) Scalable icons like SVG would be nice for the
current era of high- and low-density displays, but my understanding is that
SVG is the least well supported image format inside emacs across our
various platforms these days.

~Chad

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Wed, 22 Apr 2020 11:07:32 -0700
> Cc: Dmitry Gutov <dgutov@yandex.ru>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
> I would agree with this "not really" sentiment, but extend it to include the differences between icon themes,
> and where such things work at the OS level, between OS's. The point of icon themes is to make them all fit
> together, and the point of standardized system icons is to have them all fit together, and the users have
> shown (for many, many years now) that they understand this, and can handle the shifts with aplomb. Yes, it
> is possible for someone to install a wacky gui-customization pack that changes the left-arrow into a sausage
> and the file-folder into a rainbow, but the only people who do such things are askign for exactly that behavior,
> and aren't going to be upset that emacs' toolbar changes along with everything else. 

There's no argument that having a capability to change the set of
icons as part of a theme would be a good feature for Emacs to have.
So arguments for having that are, from my POV, preaching to the choir.

The argument, or at least its part about which I expressed concerns,
was to use exclusively the icons provided by the toolkit+desktop that
happen to be in use.  That's an entirely different matter, if we want
to make it pour policy.

> As a practical matter, emacs will need a set of reasonable fallback defaults, for systems that don't have
> system-wide settings

Only if we decide we _want_ to use those system-wide defaults where
they do exist.

> A techincal wrinkle here is how those icons are displayed and how they're stored inside emacs.

They aren't.  They are separate image files which we load when needed.
And I think it should be left that way, because it will make it easier
for us to include new icons in the distribution.

> By way of
> example, the two KDE icon sets that were suggested (Breeze and Oxygen) use different file formats: one
> uses PNG images; the other SVG. (Oddly, the SVG images are distributed in several different sizes, which
> would seem to belie the advantage of using scalable images in the first place.) Scalable icons like SVG
> would be nice for the current era of high- and low-density displays, but my understanding is that SVG is the
> least well supported image format inside emacs across our various platforms these days.

SVG is IMO a PITA because librsvg is a monster.  But other than that,
SVG images are a fait accompli, and we need to support them well.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 21:24, Eli Zaretskii wrote:
> The argument, or at least its part about which I expressed concerns,
> was to use exclusively the icons provided by the toolkit+desktop that
> happen to be in use.  That's an entirely different matter, if we want
> to make it pour policy.

Adding a user option disabling the toolkit-desktop icons and switching 
to the fallback shouldn't be too hard.

But I think it's worth our effort to try to integrate first. It's what 
users generally expect from applications, and the effect is that the 
program fits the desktop environment better. I hear this sentiment is 
particularly strong among macOS users.

Re: "Why is emacs so square?"

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On GTK, we're already there. Since 22.2, apparently. Only we haven't
> been paying attention to keeping this feature in proper maintenance.

By the way, etc/images/README says:

* The default GTK icons were not overridden by the GNOME theme due to
a bug which was fixed in GNOME 2.15. Once GNOME 2.16 is in wide
circulation, the GTK icons should be replaced with the equivalent
GNOME icons.

Does that mean there is some action that was planned but never
performed?  Gnome 2.16 was released in 2006.

Emacs on my macOS machine seems to use the icons from etc/images.  On
GNU/Linux (GTK) there is a different set of icons which arguably look
more "modern".

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 23 Apr 2020 11:42:44 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> By the way, etc/images/README says:
> 
> * The default GTK icons were not overridden by the GNOME theme due to
> a bug which was fixed in GNOME 2.15. Once GNOME 2.16 is in wide
> circulation, the GTK icons should be replaced with the equivalent
> GNOME icons.
> 
> Does that mean there is some action that was planned but never
> performed?  Gnome 2.16 was released in 2006.

Please read this longish old discussion:

  https://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00258.html

The answer to this question might be buried somewhere in it.

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 23.04.2020 18:04, Eli Zaretskii wrote:
>> From: Stefan Kangas<stefan@marxist.se>
>> Date: Thu, 23 Apr 2020 11:42:44 +0200
>> Cc: Eli Zaretskii<eliz@gnu.org>, Clément Pit-Claudel<cpitclaudel@gmail.com>,
>> 	Emacs developers<emacs-devel@gnu.org>
>>
>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>>
>> By the way, etc/images/README says:
>>
>> * The default GTK icons were not overridden by the GNOME theme due to
>> a bug which was fixed in GNOME 2.15. Once GNOME 2.16 is in wide
>> circulation, the GTK icons should be replaced with the equivalent
>> GNOME icons.
>>
>> Does that mean there is some action that was planned but never
>> performed?  Gnome 2.16 was released in 2006.
> Please read this longish old discussion:
> 
>    https://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00258.html
> 
> The answer to this question might be buried somewhere in it.

I've made an attempt, but the discussion is about copyright and 
providence of files, whereas the note seems to be about some functional 
problem.

I don't really understand it what it recommends we do now. It would seem 
as if GNOME icons can override GTK ones now (in some case where it 
couldn't before (?)), we could distribute GTK icons now and rely on 
GNOME to override them as appropriate?

Re: "Why is emacs so square?"

[Alan Third]

On Thu, Apr 23, 2020 at 11:42:44AM +0200, Stefan Kangas wrote:
> Emacs on my macOS machine seems to use the icons from etc/images.  On
> GNU/Linux (GTK) there is a different set of icons which arguably look
> more "modern".

I could be wrong, but I think some distributions swap in different
images so they better match the default look of their desktop.
-- 
Alan Third

Re: "Why is emacs so square?"

[Juan José García-Ripoll]

Eli Zaretskii <eliz@gnu.org> writes:
> "Standard" as in "subject to change without notice" each time the
> vendor decides to change the look-and-feel (which happens roughly
> every 2 to 3 years).

In Windows there are no standard icons, but a few ones signifying
warnings
(https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadicona)

This said, there are some DLLs that have broad sets of icons and that
are available, some since Windows 95, some since Windows XP. They have
not changed and can be used
https://www.digitalcitizen.life/where-find-most-windows-10s-native-icons
This webpage provides a reference by library and code
https://diymediahome.org/windows-icons-reference-list-with-details-locations-images/
However, the default set of icons is obviously deficient in that it does
not provide the icons an editor application requires: open, save, print,
etc.

Definitely I would not recommend this path, but I would encourage having
some higher resolution icons available in PNG format, for those who use
them (I disable toolbar in my computers).

Cheers

-- 
Juan José García Ripoll
http://juanjose.garciaripoll.com
http://quinfog.hbar.es

Re: "Why is emacs so square?"

[chad]

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

On Wed, Apr 22, 2020 at 9:14 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> Speaking of other platforms, I wonder if Windows and macOS also have
> have standard sets of icons.
>
> It would make our task easier (and the end result more native-looking)
> if we could use a similar approach.
>

Apple publishes a set of system icons for macOS (and its other OS's, if
that matters to anyone) as part of it's Human Interface Guidelines. These
are tweaked and updated with OS version, but usually are stable over
several major versions. The current set can be found here:
https://developer.apple.com/design/human-interface-guidelines/macos/icons-and-images/system-icons/


HTH,
~Chad

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

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 22.04.2020 17:29, Eli Zaretskii wrote:
> especially since that
> toolkit is troubled and many users avoid building with it for that
> reason.

Also, I think we're planning (at least as a wishlist item) to solve this 
my making a "proper" GTK backend instead of removing it.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 19:16:48 +0300
> 
> On 22.04.2020 17:29, Eli Zaretskii wrote:
> > especially since that
> > toolkit is troubled and many users avoid building with it for that
> > reason.
> 
> Also, I think we're planning (at least as a wishlist item) to solve this 
> my making a "proper" GTK backend instead of removing it.

Nothing practical, AFAIK.

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Wed, 22 Apr 2020 19:16:48 +0300, Dmitry Gutov <dgutov@yandex.ru> said:

    Dmitry> On 22.04.2020 17:29, Eli Zaretskii wrote:
    >> especially since that
    >> toolkit is troubled and many users avoid building with it for that
    >> reason.

    Dmitry> Also, I think we're planning (at least as a wishlist item) to solve
    Dmitry> this my making a "proper" GTK backend instead of removing it.

Making a proper GTK backend will not remove the reason that people
build with lucid, which is wanting emacs to be able to survive X
disconnects, unless we have evidence that proper GTK works in that
scenario.

It will help with things like HiDPI autoscaling, and maybe frame
resizing.

Someone in this thread mentioned they were working on a 'proper' GTK
backend, is that anywhere near useable yet?

Robert

Re: "Why is emacs so square?"

[Iñigo Serna]

On 22 April 2020 at 18:29 +02, Robert Pluim <rpluim@gmail.com> wrote:

> Someone in this thread mentioned they were working on a 'proper' GTK
> backend, is that anywhere near useable yet?

I've been lucky enough to test Po Lu's work over the last couple of
weeks, and although it's still WIP and there are still things to work on
- in my tests, mainly related to the keyboard - the result is quite stable,
and visually excellent.
For instance, look at the screenshot he attached a couple of days ago to
one of his first emails in this thread.

I don't want to steal the attention Po Lu deserves, so I won't comment
any further, and let him to show it by himself, but I'm really excited
with his work.

Regards,
Iñigo

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Wed, 22 Apr 2020 20:02:16 +0200, Iñigo Serna <inigoserna@gmx.com> said:

    Iñigo> On 22 April 2020 at 18:29 +02, Robert Pluim <rpluim@gmail.com> wrote:
    >> Someone in this thread mentioned they were working on a 'proper' GTK
    >> backend, is that anywhere near useable yet?

    Iñigo> I've been lucky enough to test Po Lu's work over the last couple of
    Iñigo> weeks, and although it's still WIP and there are still things to work on
    Iñigo> - in my tests, mainly related to the keyboard - the result is quite stable,
    Iñigo> and visually excellent.
    Iñigo> For instance, look at the screenshot he attached a couple of days ago to
    Iñigo> one of his first emails in this thread.

    Iñigo> I don't want to steal the attention Po Lu deserves, so I won't comment
    Iñigo> any further, and let him to show it by himself, but I'm really excited
    Iñigo> with his work.

As am I. Thereʼs no hurry, but I look forward to testing it.

Robert

Re: "Why is emacs so square?"

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:


> I don't think I follow.  Where can I find this "GNOME theme"?  It's
> not part of the Emacs release tarball, is it?

GTK has their own stylesheet system.  I believe that's what Dimitry was
refering to.

> What exactly do you mean by "icons follow the theme"? how does a theme
> affect icons?

It's common practice for GTK themes that change the look-and-feel a lot
to provide an accompanying XDG icon theme, and that's what the icons in
`x-gtk-stock-map` obey.

Re: "Why is emacs so square?"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Someone™ needs to invest the time and effort to figure out the legal
> issues, find the icons that we want out of those which are legally
> fit, and post the resulting information.  We did that process at the
> time (AFAIR, quite a few of our icons come from Gnome/GTK), and it
> wasn't easy.
>
> Alternatively, someone could create our own icons, in which case they
> could be even prettier than the ones pointed out here.

Would it make sense to add an entry about this to the TODO file?

Best regards,
Stefan Kangas

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 17 Apr 2020 09:36:15 +0200
> Cc: ndame <ndame@protonmail.com>, yandros@gmail.com, 
> 	Emacs developers <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > Alternatively, someone could create our own icons, in which case they
> > could be even prettier than the ones pointed out here.
> 
> Would it make sense to add an entry about this to the TODO file?

Sure, why not?  However, the entry would be more useful if it listed
the necessary requirements, legal and otherwise.

Thanks.

Re: "Why is emacs so square?"

[ndame]

>
> Someone™ needs to invest the time and effort to figure out the legal
> issues, find the icons that we want out of those which are legally
> fit, and post the resulting information. We did that process at the
> time (AFAIR, quite a few of our icons come from Gnome/GTK), and it
> wasn't easy.

What was the problem exactly? Gnome is a venerable free software
project, so I assume they pay attention to proper licensing.

Isn't their icons safe to use if they publish them with a GPL2 license?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 17 Apr 2020 08:50:07 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "dgutov@yandex.ru" <dgutov@yandex.ru>, "yandros@gmail.com" <yandros@gmail.com>, "rms@gnu.org" <rms@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> >
> > Someone™ needs to invest the time and effort to figure out the legal
> > issues, find the icons that we want out of those which are legally
> > fit, and post the resulting information. We did that process at the
> > time (AFAIR, quite a few of our icons come from Gnome/GTK), and it
> > wasn't easy.
> 
> What was the problem exactly? Gnome is a venerable free software
> project, so I assume they pay attention to proper licensing.

I'm sorry, I don't remember.  This was many years ago.  Please look in
the archives.

> Isn't their icons safe to use if they publish them with a GPL2 license?

IANAL, but I think it has to be GPL v2+ at least.  And perhaps we
would also need the copyright assigned to the FSF.

Once again, this is a non-trivial job to do, a discussion in a mailing
list will not solve it, trust me.

Re: "Why is emacs so square?"

[ndame]

>
> IANAL, but I think it has to be GPL v2+ at least. And perhaps we
> would also need the copyright assigned to the FSF.
>

The Gnome icons have GPL2 license already, so hopefully Richard can
enlighten us if copyright assignment of them to the FSF is necessary
or not.

Re: "Why is emacs so square?"

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

  > The Gnome icons have GPL2 license already,

Is it GPL version-2-only or GPL version-2-or-later?

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

Re: "Why is emacs so square?"

[Robert Pluim]

>>>>> On Fri, 17 Apr 2020 22:04:03 -0400, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> The Gnome icons have GPL2 license already,

    Richard> Is it GPL version-2-only or GPL version-2-or-later?

I think wikimedia is
outdated. <https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/COPYING>
says:

    This work is licenced under the terms of either the GNU LGPL v3 or
    Creative Commons Attribution-Share Alike 3.0 United States License.

    To view a copy of the CC-BY-SA licence, visit
    http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative
    Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.

    When attributing the artwork, using "GNOME Project" is enough.
    Please link to http://www.gnome.org where available.

(no "or later" clause, though, unless that transitively comes in via
LGPL-3 or GPL-3).

Robert

Re: "Why is emacs so square?"

[ndame]

>
> I think wikimedia is outdated.

The Gnome icons at https://commons.wikimedia.org/wiki/GNOME_Desktop_icons
are apparently for an earlier, obsolete version. I downloaded the indicated
version (gnome-icon-theme 2.20.0) and the files in it were last changed in 2007,
but the icons still look nice.

Emacs could benefit from using these icons too, even if they are obsolete,
because they are consistent and look good.

Re: "Why is emacs so square?"

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

      > This work is licenced under the terms of either the GNU LGPL v3 or

If the icons would be part of the program, Emacs, that would be the
same situation as with Qt.  No good.

      > Creative Commons Attribution-Share Alike 3.0 United States License.

That is incompatible with every version of the GPL.  If the icons
would be part of the program, Emacs, that would be no good.

If the icons would NOT be part of the program, Emacs, then there
is no conflict.

The Emacs distribution contains many works, including textual, art,
and small programs, which are distinct from the program, Emacs.



      > To view a copy of the CC-BY-SA licence, visit
      > http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative
      > Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.

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

Re: "Why is emacs so square?"

[Dmitry Gutov]

On 19.04.2020 05:20, Richard Stallman wrote:
>        > Creative Commons Attribution-Share Alike 3.0 United States License.
> 
> That is incompatible with every version of the GPL.  If the icons
> would be part of the program, Emacs, that would be no good.
> 
> If the icons would NOT be part of the program, Emacs, then there
> is no conflict.
> 
> The Emacs distribution contains many works, including textual, art,
> and small programs, which are distinct from the program, Emacs.

So, can we include them as "NOT part of the program"?

I think it's the usual approach when it comes to assets. And icons are 
not code.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 18 Apr 2020 22:20:39 -0400
> Cc: ndame@protonmail.com, emacs-devel@gnu.org
> 
>       > This work is licenced under the terms of either the GNU LGPL v3 or
> 
> If the icons would be part of the program, Emacs, that would be the
> same situation as with Qt.  No good.
> 
>       > Creative Commons Attribution-Share Alike 3.0 United States License.
> 
> That is incompatible with every version of the GPL.  If the icons
> would be part of the program, Emacs, that would be no good.
> 
> If the icons would NOT be part of the program, Emacs, then there
> is no conflict.
> 
> The Emacs distribution contains many works, including textual, art,
> and small programs, which are distinct from the program, Emacs.

What is the practical meaning of being "part of the program, Emacs" as
opposed to "being distinct from the program, Emacs"?  How does one
tell whether a given icon is in this or the other category?

E.g., we have a lot of icons in etc/images/.  We show these icons on
the tool bar and elsewhere when and where appropriate.  Are those
icons part of Emacs the program, or aren't they?

Re: "Why is emacs so square?"

[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 is the practical meaning of being "part of the program, Emacs" as
  > opposed to "being distinct from the program, Emacs"?  How does one
  > tell whether a given icon is in this or the other category?

It is a legal question.  If a file of code is under the GPL, the
GPL applies to the entire program or work that the file is part of.

But it does not apply to other, separate works that are distributed
WITH that program or work.  Separate in regard to copyright law, I
mean.

I don't know a simple way to describe this, sorry.

  > E.g., we have a lot of icons in etc/images/.  We show these icons on
  > the tool bar and elsewhere when and where appropriate.  Are those
  > icons part of Emacs the program, or aren't they?

I think it depends on how things work to display those images.
And I don't remember that.

When Emacs wants to display etc/images/attach.pbm, how does that work?
Does attach.pbm get somehow linked into Emacs?  Or does Emacs open
etc/images/attach.pbm at run time, read it, and display it?

With the first method, they are part of one combined work.

With the second method, it is valid to say they are two separate works
and treat them as such.

At least, such is the understanding I got from lawyers around 30 years ago.

With two _programs_, the issue is different.

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: rpluim@gmail.com, emacs-devel@gnu.org, ndame@protonmail.com
> Date: Sun, 19 Apr 2020 22:18:58 -0400
> 
>   > E.g., we have a lot of icons in etc/images/.  We show these icons on
>   > the tool bar and elsewhere when and where appropriate.  Are those
>   > icons part of Emacs the program, or aren't they?
> 
> I think it depends on how things work to display those images.
> And I don't remember that.
> 
> When Emacs wants to display etc/images/attach.pbm, how does that work?
> Does attach.pbm get somehow linked into Emacs?  Or does Emacs open
> etc/images/attach.pbm at run time, read it, and display it?

It's the latter.  More accurately, we look up the file in the
filesystem, then pass the full file name to an image library which we
link with Emacs, and that library reads it.  And many icon files come
with every Emacs tarball and in any binary distribution, of course.

> With the first method, they are part of one combined work.
> 
> With the second method, it is valid to say they are two separate works
> and treat them as such.

So since this is the second method, what are the legal requirements
from icon files that we bundle with Emacs?  Just a free license?  And
if so, what kind of license?  Are there any other requirements?

Thanks.

Re: "Why is emacs so square?"

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

  > So since this is the second method, what are the legal requirements
  > from icon files that we bundle with Emacs?  Just a free license?

Yes.  Any free license will do, for the icons.

  >   And
  > if so, what kind of license?

No particular kind is required, but it shouldn't be a weird one.

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

Re: "Why is emacs so square?"

[ndame]

Sent with ProtonMail Secure Email.

>
> > So since this is the second method, what are the legal requirements
>
> > from icon files that we bundle with Emacs? Just a free license?
>
> Yes. Any free license will do, for the icons.


I checked the KDE icons too and they have this text for license (excerpts):

    This library is free software; you can redistribute it and/or
    modify it under the terms of the GNU Lesser General Public
    License as published by the Free Software Foundation; either
    version 3 of the License, or (at your option) any later version.


Clarification:

  The GNU Lesser General Public License or LGPL is written for
  software libraries in the first place. We expressly want the LGPL to
  be valid for this artwork library too.

  KDE Oxygen theme icons is a special kind of software library, it is an
  artwork library, it's elements can be used in a Graphical User Interface, or
  GUI.




It contains the later version clause too for LGPL, so I guess the problem
of icons is solved.


There is a choice too, both of these have this license. Emacs could even
offer a choice of icon themes for the user:


https://github.com/KDE/oxygen-icons/


https://github.com/KDE/breeze-icons/

Re: "Why is emacs so square?"

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

      > This library is free software; you can redistribute it and/or
      > modify it under the terms of the GNU Lesser General Public
      > License as published by the Free Software Foundation; either
      > version 3 of the License, or (at your option) any later version.

That is a free license, compatible with GPL 3, and will be compatible
with future GPL versions as well.

We've determined that the icons are separate works from Emacs.  So
we do not need their licenses to be compatible with any GPL versions.
We just need them to carry a reasonable free license.


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

Re: "Why is emacs so square?"

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

  > There are also the KDE icon set, though it's LGPL 3 licensed.
  > I don't know if it's OK in Emacs:

If they are LGPL 3 only, I think they can't be part of a GPL-4-covered
work.  However, the icons Emacs uses may not actually be part of
Emacs, the program.  If they are not part of Emacs, the program, they
could have any license as long as it is free.  But I'd have to ask a
lawyer about it.

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

Re: "Why is emacs so square?"

[Bob Newell]

> The other option, of course, is to look both modern and unique, but it's
> a harder proposition, especially without a graphical designer on the
> team. And this stuff gets outdated quickly.

That's the problem. What's hip today is passé tomorrow. The "modern"
look of Windows 3.1 is considered ancient and dated today. But do
today's GUIs offer more (or perhaps less!) user value?

In my initial attempt to be sarcastic, I unfortunately took too
extreme a position. so I'll say now that there is nothing wrong with
an Emacs GUI that provides true user value, and if it looks nice,
that's a plus. (But I too go to the extreme of pure text, no frills,
touchpad disabled, etc. ... it's what works for me.)

However I would (humbly this time) suggest that whatever is done in
terms of appearance not interfere with the things that make Emacs the
tool that it is.

-- 
Bob Newell
Honolulu, Hawai`i

Via Linux/Emacs/Gnus/BBDB.

Re: "Why is emacs so square?"

[Bob Newell]

> It could improve the square apperance if, for example, emacs provided
> some text
> properties to specify rounded corners with custom radius for
> background colors.

Oh yes, because everyone chooses Emacs for hipster graphics
rather than for a free, sophisticated tool that lets you get
work done.

You might want to try Notepad on Windows 10 or something.

-- 
Bob Newell
Honolulu, Hawai`i
- Via Gnus/BBDB/Org/Emacs/Linux

Re: "Why is emacs so square?"

[Jean-Christophe Helary]

> On Apr 15, 2020, at 12:35, Bob Newell <bobnewell@bobnewell.net> wrote:
> 
> 
> 
>> It could improve the square apperance if, for example, emacs provided
>> some text
>> properties to specify rounded corners with custom radius for
>> background colors.
> 
> Oh yes, because everyone chooses Emacs for hipster graphics
> rather than for a free, sophisticated tool that lets you get
> work done.
> 
> You might want to try Notepad on Windows 10 or something.

Or you might want to think about how to provide a way to accomplish that?

That's probably more in the spirit of free software than to send people to use a non free tool, isn't it ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Bob Newell <bobnewell@bobnewell.net>
> Date: Tue, 14 Apr 2020 17:35:06 -1000
> 
> You might want to try Notepad on Windows 10 or something.

Which won't help, because the Windows 10 look and feel doesn't include
rounded corners of windows, at least not by default.

Re: "Why is emacs so square?"

[Tim Cross]

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

I think the challenge would be in coming up with an approach which won't
make the terminal (non-gui) version drift from the GUI version too much.
Changing the button styles etc in the GUI menu and perhaps updating toolbar
icons etc is probably not too hard, but you cannot do much with things like
'buttons' in widgets etc (such as those used with customize) without having
to have completely different code for rendering in GUI and rendering in
terminal. This would potentially blow out maintenance and create two code
bases to manage and lets face it, one is more than enough.

I think part of the reason the GUI menus and toolbar might look dated to
many is that nearly all experienced and long-term users I know turn off the
menus and toolbar, so never see them. It has been years since I've used
either. For me, the only 'buttons' I see are the widget style buttons and
these are not really buttons - they are really text 'fake' buttons. I would
also be a little concerned about impact any attempt to change these might
have on performance (we already have quite a long thread about rendering
performance).

Just my 2 cents....


On Wed, 15 Apr 2020 at 16:35, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Bob Newell <bobnewell@bobnewell.net>
> > Date: Tue, 14 Apr 2020 17:35:06 -1000
> >
> > You might want to try Notepad on Windows 10 or something.
>
> Which won't help, because the Windows 10 look and feel doesn't include
> rounded corners of windows, at least not by default.
>
>

-- 
regards,

Tim

--
Tim Cross

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

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Wed, 15 Apr 2020 23:57:18 +1000
> Cc: Bob Newell <bobnewell@bobnewell.net>, Emacs developers <emacs-devel@gnu.org>
> 
> I think the challenge would be in coming up with an approach which won't make the terminal (non-gui)
> version drift from the GUI version too much. Changing the button styles etc in the GUI menu and perhaps
> updating toolbar icons etc is probably not too hard, but you cannot do much with things like 'buttons' in
> widgets etc (such as those used with customize) without having to have completely different code for
> rendering in GUI and rendering in terminal.

Maybe I'm missing something, but AFAIK we already have different code
for rendering this stuff in GUI and in text-mode frames. The GUI code
inserts an image and simulates the 3D "raised button" appearance,
whereas the text-mode code shows some ASCII art instead.

Or maybe I don't understand what differences you had in mind.

> I think part of the reason the GUI menus and toolbar might look dated to many is that nearly all experienced
> and long-term users I know turn off the menus and toolbar, so never see them.

Well, I don't, FWIW.

> For me, the only 'buttons' I see are the widget style buttons and these are not really buttons -
> they are really text 'fake' buttons.

Not sure what you mean by "text fake buttons".  We show a 3D
appearance on button widgets; if that's not real buttons, then what
should real buttons look like, in your opinion?

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 15/04/2020 10.09, Eli Zaretskii wrote:
>> From: Tim Cross <theophilusx@gmail.com>
>> For me, the only 'buttons' I see are the widget style buttons and these are not really buttons -
>> they are really text 'fake' buttons.
> 
> Not sure what you mean by "text fake buttons".  We show a 3D
> appearance on button widgets

Sometimes we do and sometimes we don't.  With my current emacs configuration, for example, I get buttons that look like this on graphical frames:

 Operate on all settings in this buffer:
 [ Revert... ] [ Apply ] [ Apply and Save ]

I think this is due to custom-raised-buttons being nil, which happens if cus-edit gets loaded too early in an Emacs server, as in the following example:

  echo "(require 'cus-edit)" > ~/.emacs
  emacsclient --alternate-editor="" --create-frame 

In the resulting graphical frame, customize buffers won't use 3D buttons.  Tim, what is the value of custom-raised-buttons in your session?

Should I open a bug report?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 16 Apr 2020 13:03:03 -0400
> 
>  Operate on all settings in this buffer:
>  [ Revert... ] [ Apply ] [ Apply and Save ]
> 
> I think this is due to custom-raised-buttons being nil, which happens if cus-edit gets loaded too early in an Emacs server, as in the following example:
> 
>   echo "(require 'cus-edit)" > ~/.emacs
>   emacsclient --alternate-editor="" --create-frame 
> 
> In the resulting graphical frame, customize buffers won't use 3D buttons.  Tim, what is the value of custom-raised-buttons in your session?
> 
> Should I open a bug report?

I think it's a bug in your ~/.emacs, so a bug report will hardly solve
it.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 16/04/2020 13.22, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 16 Apr 2020 13:03:03 -0400
>>
>>  Operate on all settings in this buffer:
>>  [ Revert... ] [ Apply ] [ Apply and Save ]
>>
>> I think this is due to custom-raised-buttons being nil, which happens if cus-edit gets loaded too early in an Emacs server, as in the following example:
>>
>>   echo "(require 'cus-edit)" > ~/.emacs
>>   emacsclient --alternate-editor="" --create-frame 
>>
>> In the resulting graphical frame, customize buffers won't use 3D buttons.  Tim, what is the value of custom-raised-buttons in your session?
>>
>> Should I open a bug report?
> 
> I think it's a bug in your ~/.emacs, so a bug report will hardly solve
> it.

I think there is a misunderstanding.  The recipe I posted above is self-contained and reproduces the issue.
The problem is that custom-raised-buttons is initialized once and for all to a value that depends on whether the current frame when cus-edit is loaded is a graphical frame.  Then all other frames, graphical or not, use that value.

Clément.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 16 Apr 2020 14:11:40 -0400
> 
> > I think it's a bug in your ~/.emacs, so a bug report will hardly solve
> > it.
> 
> I think there is a misunderstanding.  The recipe I posted above is self-contained and reproduces the issue.

Of course.  Which is why I think I understand the issue.

> The problem is that custom-raised-buttons is initialized once and for all to a value that depends on whether the current frame when cus-edit is loaded is a graphical frame.  Then all other frames, graphical or not, use that value.

Initialization of stuff that depends on GUI frames and should work in
client frames needs to be done in server-after-make-frame-hook.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 16/04/2020 14.21, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 16 Apr 2020 14:11:40 -0400
>>
>>> I think it's a bug in your ~/.emacs, so a bug report will hardly solve
>>> it.
>>
>> I think there is a misunderstanding.  The recipe I posted above is self-contained and reproduces the issue.
> 
> Of course.  Which is why I think I understand the issue.
> 
>> The problem is that custom-raised-buttons is initialized once and for all to a value that depends on whether the current frame when cus-edit is loaded is a graphical frame.  Then all other frames, graphical or not, use that value.
> 
> Initialization of stuff that depends on GUI frames and should work in
> client frames needs to be done in server-after-make-frame-hook.

I think I don't understand this part :/

To be clear, the bug that I'm talking about is that, when using the Emacs server, requiring cus-edit during initialization causes buttons to be displayed as text, not as 3D buttons.
It's really easy to run into this without realizing it.  For example, installing the `validate' package from Elpa will do it:

  emacs -Q --eval '(setq user-emacs-directory "/tmp/emacs-sandbox")' \
    -l package \
    --eval "(package-refresh-contents)" \
    --eval "(package-initialize)" \
    --eval "(package-install 'validate)" \
    --daemon

  emacsclient --create-frame # This frame doesn't use 3D buttons in e.g. customize-face

Alternatively, installing the package manually and putting `(require 'validate)` in your .emacs to be able to use (validate-setq tab-width 4) will also cause issues.

What am I missing?
Clément.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 16/04/2020 14.21, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 16 Apr 2020 14:11:40 -0400
>>
>>> I think it's a bug in your ~/.emacs, so a bug report will hardly solve
>>> it.
>>
>> I think there is a misunderstanding.  The recipe I posted above is self-contained and reproduces the issue.
> 
> Of course.  Which is why I think I understand the issue.

Following up on my previous message, I'd argue that the following is also a problem, btw:

  emacs -Q --daemon
  emacsclient --alternate-editor="emacs -Q" --nw # In this window, run M-x customize-face RET bold RET then exit
  emacsclient --alternate-editor="emacs -Q" --create-frame # In this window, run M-x customize-face RET bold RET

The second customization window doesn't have 3D buttons.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 16 Apr 2020 15:52:54 -0400
> 
>   emacs -Q --daemon
>   emacsclient --alternate-editor="emacs -Q" --nw # In this window, run M-x customize-face RET bold RET then exit
>   emacsclient --alternate-editor="emacs -Q" --create-frame # In this window, run M-x customize-face RET bold RET
> 
> The second customization window doesn't have 3D buttons.

Because your Emacs was started as a daemon.

Re: "Why is emacs so square?"

[Stefan Monnier]

>>   emacs -Q --daemon
>>   emacsclient --alternate-editor="emacs -Q" --nw # In this window, run M-x
>> customize-face RET bold RET then exit
>>   emacsclient --alternate-editor="emacs -Q" --create-frame # In this
>> window, run M-x customize-face RET bold RET
>> 
>> The second customization window doesn't have 3D buttons.
>
> Because your Emacs was started as a daemon.

No, it's only because the first use of customize was on a tty frame.
The same happens if you

    emacs -Q -nw
    M-x customize-face ...
    M-x make-frame-on-display ...
    M-x customize-face ...


-- Stefan

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 03.09, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 16 Apr 2020 15:52:54 -0400
>>
>>   emacs -Q --daemon
>>   emacsclient --alternate-editor="emacs -Q" --nw # In this window, run M-x customize-face RET bold RET then exit
>>   emacsclient --alternate-editor="emacs -Q" --create-frame # In this window, run M-x customize-face RET bold RET
>>
>> The second customization window doesn't have 3D buttons.
> 
> Because your Emacs was started as a daemon.

As Stefan pointed out, this isn't due to the daemon.  But even so, starting Emacs as a daemon shouldn't break 3D buttons.

A few messages ago, the following discussion happened:

>> For me, the only 'buttons' I see are the widget style buttons and these are not really buttons -
>> they are really text 'fake' buttons.
> 
> Not sure what you mean by "text fake buttons".  We show a 3D
> appearance on button widgets

I was just pointing out that in may cases we don't show a 3D appearance on button widgets.  You also wrote:

> Maybe I'm missing something, but AFAIK we already have different code
> for rendering this stuff in GUI and in text-mode frames. The GUI code
> inserts an image and simulates the 3D "raised button" appearance,
> whereas the text-mode code shows some ASCII art instead.
The code is here:

(defcustom custom-raised-buttons (not (equal (face-valid-attribute-values :box)
					     '(("unspecified" . unspecified))))
  "If non-nil, indicate active buttons in a raised-button style.
Otherwise use brackets."
  :type 'boolean
  :version "21.1"
  :group 'custom-buffer
  :set (lambda (variable value)
	 (custom-set-default variable value)
	 (setq custom-button
	       (if value 'custom-button 'custom-button-unraised))
	 (setq custom-button-mouse
	       (if value 'custom-button-mouse 'highlight))
	 (setq custom-button-pressed
	       (if value
		   'custom-button-pressed
		 'custom-button-pressed-unraised))))

This definition is evaluated once and for all, instead of once per frame.  Isn't that a bug?

Clément.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 10:13:58 -0400
> Cc: emacs-devel@gnu.org
> 
> This definition is evaluated once and for all, instead of once per frame.  Isn't that a bug?

I don't know.  AFAIK, we don't have infrastructure for deciding when
stuff like that needs to be re-evaluated and how to use different
results for different frames.  If someone wants to work on such
infrastructure, I think it will bring us a step closer to being able
to support different GUI frame types (like GTK, w32, NS, etc.) in the
same session.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

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

On 17/04/2020 10.46, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 17 Apr 2020 10:13:58 -0400
>> Cc: emacs-devel@gnu.org
>>
>> This definition is evaluated once and for all, instead of once per frame.  Isn't that a bug?
> 
> I don't know.  AFAIK, we don't have infrastructure for deciding when
> stuff like that needs to be re-evaluated and how to use different
> results for different frames.  If someone wants to work on such
> infrastructure, I think it will bring us a step closer to being able
> to support different GUI frame types (like GTK, w32, NS, etc.) in the
> same session.

I may be missing something, but I don't think such infrastructure is needed here — we already have most of what's needed with conditional faces.  The attached patch gets us 90% of the way, with the only remaining issue being wrapping buttons in square brackets on text terminals.

We'd also need a similar trick for check-boxes and the like.

WDYT?

[-- Attachment #2: custom-raised-buttons.diff --]
[-- Type: text/x-patch, Size: 1865 bytes --]

diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index d3d17fda7a..2f29a00de2 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -1599,8 +1599,7 @@ custom-search-field
   :version "24.1"
   :group 'custom-buffer)
 
-(defcustom custom-raised-buttons (not (equal (face-valid-attribute-values :box)
-					     '(("unspecified" . unspecified))))
+(defcustom custom-raised-buttons t
   "If non-nil, indicate active buttons in a raised-button style.
 Otherwise use brackets."
   :type 'boolean
@@ -2113,7 +2112,8 @@ custom-magic-reset
 (defface custom-button
   '((((type x w32 ns) (class color))	; Like default mode line
      :box (:line-width 2 :style released-button)
-     :background "lightgrey" :foreground "black"))
+     :background "lightgrey" :foreground "black")
+    (t :inherit custom-button-unraised))
   "Face for custom buffer buttons if `custom-raised-buttons' is non-nil."
   :version "21.1"
   :group 'custom-faces)
@@ -2137,17 +2137,23 @@ custom-button-unraised
   :version "22.1"
   :group 'custom-faces)
 
+(defface custom-button-mouse-unraised
+  '((t :inherit highlight))
+  "Mouse face for custom buffer buttons if `custom-raised-buttons' is nil."
+  :version "22.1"
+  :group 'custom-faces)
+
 (setq custom-button
       (if custom-raised-buttons 'custom-button 'custom-button-unraised))
 
 (setq custom-button-mouse
-      (if custom-raised-buttons 'custom-button-mouse 'highlight))
+      (if custom-raised-buttons 'custom-button-mouse 'custom-button-mouse-unraised))
 
 (defface custom-button-pressed
   '((((type x w32 ns) (class color))
      :box (:line-width 2 :style pressed-button)
      :background "lightgrey" :foreground "black")
-    (t :inverse-video t))
+    (t :inherit custom-button-pressed-unraised))
   "Face for pressed custom buttons if `custom-raised-buttons' is non-nil."
   :version "21.1"
   :group 'custom-faces)

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 11:27:56 -0400
> 
> > I don't know.  AFAIK, we don't have infrastructure for deciding when
> > stuff like that needs to be re-evaluated and how to use different
> > results for different frames.  If someone wants to work on such
> > infrastructure, I think it will bring us a step closer to being able
> > to support different GUI frame types (like GTK, w32, NS, etc.) in the
> > same session.
> 
> I may be missing something, but I don't think such infrastructure is needed here — we already have most of what's needed with conditional faces.

Faces were always per-frame (although when you customize a face, it
changes on all frames), but faces are just the tip of the iceberg.
The general problem with GUI features is much wider.  I thought you
were talking about the more general problem.

> The attached patch gets us 90% of the way, with the only remaining issue being wrapping buttons in square brackets on text terminals.
> 
>  (defface custom-button-pressed
>    '((((type x w32 ns) (class color))
>       :box (:line-width 2 :style pressed-button)
>       :background "lightgrey" :foreground "black")
> -    (t :inverse-video t))
> +    (t :inherit custom-button-pressed-unraised))
>    "Face for pressed custom buttons if `custom-raised-buttons' is non-nil."
>    :version "21.1"
>    :group 'custom-faces)

Why a separate face, instead of a separate definition of the same face
for non-GUI displays?

Anyway, the condition should not be on frame types, but rather on
capabilities, IMO.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 11.38, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 17 Apr 2020 11:27:56 -0400
>>
>>> I don't know.  AFAIK, we don't have infrastructure for deciding when
>>> stuff like that needs to be re-evaluated and how to use different
>>> results for different frames.  If someone wants to work on such
>>> infrastructure, I think it will bring us a step closer to being able
>>> to support different GUI frame types (like GTK, w32, NS, etc.) in the
>>> same session.
>>
>> I may be missing something, but I don't think such infrastructure is needed here — we already have most of what's needed with conditional faces.
> 
> Faces were always per-frame (although when you customize a face, it
> changes on all frames), but faces are just the tip of the iceberg.
> The general problem with GUI features is much wider.  I thought you
> were talking about the more general problem.

I'm talking only about the OP's problem, which was that buttons were not displayed in 3D.

>> The attached patch gets us 90% of the way, with the only remaining issue being wrapping buttons in square brackets on text terminals.
>>
>>  (defface custom-button-pressed
>>    '((((type x w32 ns) (class color))
>>       :box (:line-width 2 :style pressed-button)
>>       :background "lightgrey" :foreground "black")
>> -    (t :inverse-video t))
>> +    (t :inherit custom-button-pressed-unraised))
>>    "Face for pressed custom buttons if `custom-raised-buttons' is non-nil."
>>    :version "21.1"
>>    :group 'custom-faces)
> 
> Why a separate face, instead of a separate definition of the same face
> for non-GUI displays?

To be able to honor the custom-raised-buttons setting.  I wouldn't design it that way, but that's where we are.

> Anyway, the condition should not be on frame types, but rather on
> capabilities, IMO.

Agreed.
Do you know how the problem with square brackets could be solved?  Currently the custom-raised-buttons setting is used to chose a face and to decide whether to insert square brackets around buttons. Is there a clean way to make these brackets display only in text terminals?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 11:52:56 -0400
> 
> Do you know how the problem with square brackets could be solved?

Sorry, no.  Custom was always a dark corner for me.

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 13.16, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 17 Apr 2020 11:52:56 -0400
>>
>> Do you know how the problem with square brackets could be solved?
> 
> Sorry, no.  Custom was always a dark corner for me.

Me too, but fortunately this isn't a question about custom, it's a question about features about the display engine.  

There is a way to change the color, backgorund, etc. of a bit of text depending on the properties of the display it is on, through the face-specs of defface.  Is there a similar facility for showing or hiding a piece of text depending on properties of the frame it's shown on?  I tried using a conditional 'display property, but that doesn't seem to work.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 13:40:29 -0400
> 
> There is a way to change the color, backgorund, etc. of a bit of text depending on the properties of the display it is on, through the face-specs of defface.  Is there a similar facility for showing or hiding a piece of text depending on properties of the frame it's shown on?  I tried using a conditional 'display property, but that doesn't seem to work.

I don't think I understand the problem.  Faces can have different
definitions on different frames, so what is the problem, exactly?

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 13.45, Eli Zaretskii wrote:
>> Cc: emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 17 Apr 2020 13:40:29 -0400
>>
>> There is a way to change the color, backgorund, etc. of a bit of text depending on the properties of the display it is on, through the face-specs of defface.  Is there a similar facility for showing or hiding a piece of text depending on properties of the frame it's shown on?  I tried using a conditional 'display property, but that doesn't seem to work.
> 
> I don't think I understand the problem.  Faces can have different
> definitions on different frames, so what is the problem, exactly?

The problem is to indicate that a string is a button on a text terminal.  Currently, custom does this by writing the string "[button]" with an underline on text terminals, and "button" with a raised look on graphical terminals.

This is done by inserting different text in the buffer depending on whether the display supports the `:box' face property.  Because of this, a customization buffer created on a text terminal shows "[button]" instead of "button" when displayed on a graphical terminal.

The question is: is there a way to insert something in a buffer that will display as "[button]" when shown on a text terminal and as "button" when shown on a graphical terminal?
I thought of using something like (propertize "[" 'display '(when (display-graphic-p) . "")), but it doesn't work well: when the buffer is shown on two frames (one graphical, one non-graphical), it doesn't look right in both.

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 17 Apr 2020 13:57:05 -0400
> 
> The question is: is there a way to insert something in a buffer that will display as "[button]" when shown on a text terminal and as "button" when shown on a graphical terminal?

Did you try using an image?

Re: "Why is emacs so square?"

[Eli Zaretskii]

> Date: Fri, 17 Apr 2020 21:36:27 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Did you try using an image?

Or a window-specific overlay?

And btw, in the conditional 'display' spec, did you call
display-graphic-p with a frame argument?

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 14.51, Eli Zaretskii wrote:
>> Date: Fri, 17 Apr 2020 21:36:27 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> Did you try using an image?

I did not.  Interesting thought! But since I need the "[" on graphical terminals, I'd use a replacement spec that says to show an empty image on graphical terminals, is that right?

> Or a window-specific overlay?

Interesting! But wouldn't I need to re-create the overlays every time the buffer is displayed in a new window?

> And btw, in the conditional 'display' spec, did you call
> display-graphic-p with a frame argument?

Yes, here's the full test:

(defface my-button
  '((((type x w32 ns) (class color))
     :box (:line-width -1 :style released-button)
     :background "lightgrey" :foreground "black")
    (t :inherit underline))
  "Button face"
  :group 'flycheck-faces)

(with-current-buffer (get-buffer-create "button")
  (insert (propertize "[" 'display '(when (display-graphic-p (selected-frame)) . "")))
  (insert (propertize "button" 'face 'my-button))
  (insert (propertize "]" 'display '(when (display-graphic-p (selected-frame)) . ""))))

I put this code in button.el, then I run emacs like this:

  emacs -Q -nw -l button.el 

I display the buffer in the terminal; it looks like this: [button] with "button" underlined

Then I use M-x make-frame-on-display :0 to show the same buffer in a graphical frame.  I see this: [button] with a 3D face on "button".  If I move the point, the brackets disappear on both frames (the terminal one and the graphic one.  If I switch back to the terminal frame, the brackets reappear on both frames.

Clément.

Re: "Why is emacs so square?"

[Stefan Monnier]

> (with-current-buffer (get-buffer-create "button")
>   (insert (propertize "[" 'display '(when (display-graphic-p (selected-frame)) . "")))
>   (insert (propertize "button" 'face 'my-button))
>   (insert (propertize "]" 'display '(when (display-graphic-p (selected-frame)) . ""))))

My guess is that the (selected-frame) at the time the code is run might
not be the one you think.  Maybe we should change/fix that (we had the
same problem when computing the mode/header lines).


        Stefan

Re: "Why is emacs so square?"

[Clément Pit-Claudel]

On 17/04/2020 16.14, Stefan Monnier wrote:
>> (with-current-buffer (get-buffer-create "button")
>>   (insert (propertize "[" 'display '(when (display-graphic-p (selected-frame)) . "")))
>>   (insert (propertize "button" 'face 'my-button))
>>   (insert (propertize "]" 'display '(when (display-graphic-p (selected-frame)) . ""))))
> 
> My guess is that the (selected-frame) at the time the code is run might
> not be the one you think.  Maybe we should change/fix that (we had the
> same problem when computing the mode/header lines).

Doesn't look like it, from this test:

(with-current-buffer (get-buffer-create "button")
  (insert (propertize "[" 'display '(when (and (message "[%f] On frame %S: %S"
                                                        (float-time)
                                                        (selected-frame)
                                                        (display-graphic-p (selected-frame)))
                                               (display-graphic-p (selected-frame))) . "graphic")))
  (insert (propertize "button" 'face 'my-button))
  (insert (propertize "]" 'display '(when (display-graphic-p (selected-frame)) . ""))))

Clicking in the graphical frame reevaluates in both, and the terminal one does see nil.  Clicking in the terminal frame reevaluates only there.  In both cases the display is updated in all windows (on all frames).

Re: "Why is emacs so square?"

[Andreas Schwab]

On Apr 15 2020, Tim Cross wrote:

> icons etc is probably not too hard, but you cannot do much with things like
> 'buttons' in widgets etc (such as those used with customize) without having
> to have completely different code for rendering in GUI and rendering in
> terminal.

I don't think that is a problem, they already have different rendering
today.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: "Why is emacs so square?"

[Emanuel Berg via Emacs development discussions.]

ndame wrote:

> A user on reddit [...]

https://www.reddit.com/r/emacs/comments/23vtvd/why_is_emacs_sosquare/

> It could improve the square apperance if, for example,
> emacs provided some text properties to specify rounded
> corners with custom radius for background colors.

The thing is, you only care for decorations for a very
short time. After that, you want it as to the point
as possible.

I'm not a GUI Emacs user, but I give you half right
because last time I saw the default GUI Emacs on X it
looked like a Windows 95 application.

OTOH I'm unsure if Emacs does its own buttons. It does?
Or do they conform to the underlying look and feel, in
which case maybe one should configure the underlying OS
(e.g., the window manager, graphical/widget toolkit,
Xresources etc).

My opinion is we should make Emacs look _so cool_, and
then when people start using it they'll just remove
everything (but continue to use Emacs).

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

Re: "Why is emacs so square?"

[Christopher Lemmer Webber]

"Why is emacs so square?"

 - It was the easiest way to delineate the M-x zone!
 - We needed a shape that would save us from fitting in the kill ring!
 - Yow!  Are we feeling square yet?
 - Is it because why is emacs so square though that you came to me?
 - Emacs' lisp lead to social stigmitization that meant it never was
   accepted into the cool crowd!