RE: Sv: Emacs Survey: Toolbars

RE: Sv: Emacs Survey: Toolbars

[Drew Adams]

> Those things we "just" have to do, must be done, otherwise we cannot
> claim to be anywhere near a word processor, because it is unimaginable
> in a word processor to apply faces via Edit->Text Properties, let
> alone via lower-level commands.
> 
> And the next thing to do is the ability to save all that face
> information to a disk file, so that the next time you visit the file
> you see the same faces.  Enriched mode does that, but it needs more
> love.
> 
> Next after that is pixel-level indentation and filling/justification,
> so that we could use variable-pitch fonts.
> 
> Next are the printing facilities, where I hope we will once and for
> all solve the problem of printing non-ASCII, non-Latin-1 characters.
> 
> When we have done all that, we will have a significant portion of a
> word processor, IMO.

I concur.  That's a fair amount of basic stuff
to provide, as stepping stones.  And each bit
of it would be useful in its own right and for
other purposes as well.
___

Wrt "it is unimaginable in a word processor to
apply faces via Edit->Text Properties", FWIW:

Some of my code can help with on-demand, ad
hoc highlighting.  And yes, it's on Edit >
Text Properties.  But it could be put on
tool-bar buttons or whatever.  And of course
other implementations of such basic features
are possible, and would no doubt be chosen to
provide performance as the basis of low-level,
built-in word-processing.
___

Examples:

Apply a color or face by dragging the mouse
like a highlighter pen:

1. Edit > Text Properties > Highlight >
   Highlighter Pen
2. Drag mouse to highlight text dragged over.

Apply a color or face to a selection (region):

1. Select text.
2. Right-click `mouse-3' twice (slower than a
   double-click).
3. Choose Highlight > Highlight in the popup
   menu.

Apply a color or face to a symbol at point:

1. Right-click `mouse-3' twice (slower than a
   double-click).
2. Choose Thing At Pointer > Highlight Symbol
   in the popup menu.

Do the same, but using hi-lock (highlight all
occurrences of the symbol):

1. Same.
2. Choose Thing At Pointer > Hi-Lock Symbol
   in the popup menu.

Choose a color or face to use for all such
highlighting operations (and others):

1. Edit > Text Properties > Highlight >
   Choose Highlighting Face
2. Choose a color or a face (for background)
   using completion.

Critical to choosing a color or face is the
ability to see a sample associated with its
name (the completion candidate).

There are several pieces that combine to
provide such behavior.  Of course things could
be done (implemented or organized) differently.
I'm just pointing out some pieces as food for
thought.

1. For showing samples along with color and face
name completion candidates, i.e., WYSIWYG, I use
Icicles.  (Icicles lets you match RGB hex codes
as well as color names.)  I imagine that some
other completion frameworks offer something
similar, or could do so.

Screenshots:

https://www.emacswiki.org/emacs/Icicles_-_Screenshots#icicle-read-color

(I also have library `palette.el', which gives
you a complete color picker, and library
`eyedropper.el', which just picks the foreground
or background color at cursor or pointer.  Some
of the display quality of `palette.el' has been
degraded by changes to Emacs, and I haven't kept
up with fixing that, but it still works.)

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

https://www.emacswiki.org/emacs/download/eyedropper.el

2. For highlighting by dragging the mouse, and
for choosing a color/face for that, I use
library `highlight.el'.

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

3. For putting that on a Highlight menu under
Edit > Text Properties I use `facemenu+.el'.

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

4. For highlighting on a `mouse-3' popup menu I
use library `mouse3.el'.

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

RE: Internationalize Emacs's messages (swahili)

[Drew Adams]

> > Actually, AFAICT this all started from:
> >   (not (null (cdr deleted))) would avoid traversing
> >   the entire list, but it wouldn't be easier to read.
> 
> No, it started from (> (length LIST) 1) being a waste of cycles.

I can't believe this thread is going on & on about this.

Users need _anyway_ to learn that `length' traverses the
entire list.  And it's not the only function that does so.
This is part of learning Lisp (and not just Lisp).

All of your machinations to create additional functions
to "help" users avoid the gotcha of using `length' when
it's not needed won't really help, is my guess.

With that "solution" you've only added a new problem: you
now need to advertise the new functions and advise users
to use them, not `length', in such a use case.  Which
means you still have the need to identify the relevant use
cases, which means teach them about the `length' gotcha
(or hope they follow advice without understanding).  IOW,
now you have 2 problems...

This seems like a classic case of going against Occam's,
Razor, i.e., a case of multiplying things needlessly.
___

[Personally, in the case considered, I'd use (cdr x).
I wouldn't use (not (null (cdr x))).  And it doesn't
get simpler _or clearer_ than that, IMO.]

lengths and stuff

[Daniel Brooks]

Drew Adams <drew.adams@oracle.com> writes:

> With that "solution" you've only added a new problem: you
> now need to advertise the new functions and advise users
> to use them, not `length', in such a use case.  Which
> means you still have the need to identify the relevant use
> cases, which means teach them about the `length' gotcha
> (or hope they follow advice without understanding).  IOW,
> now you have 2 problems...

Users certainly do need to know the performance cost of the functions
that they use. But they also need alternatives. If (> (length list) n)
is a trap for new players, then document it as so _and_ mention that
there is a specific function that can be used to avoid the trap. But
it's also worth mentioning that maybe the code should use a vector
instead of a list, if the length is so important.

Also, as was pointed out, this very thing happens 735 times in the Emacs
lisp codebase. Probably most of those have no great performance impact,
but it's a good observation.

> [Personally, in the case considered, I'd use (cdr x).
> I wouldn't use (not (null (cdr x))).  And it doesn't
> get simpler _or clearer_ than that, IMO.]

True. It's not the first time I've noticed myself making something more
complicated by eagerly converting to a boolean. But I still don't think
that it's readable code.

db48x

RE: lengths and stuff

[Drew Adams]

> -----Original Message-----
> From: Daniel Brooks <db48x@db48x.net>
> Sent: Saturday, December 26, 2020 8:59 PM
> To: Drew Adams <drew.adams@oracle.com>
> Cc: Eli Zaretskii <eliz@gnu.org>; Stefan Monnier <monnier@iro.umontreal.ca>;
> larsi@gnus.org; emacs-devel@gnu.org
> Subject: lengths and stuff
> 
> Drew Adams <drew.adams@oracle.com> writes:
> 
> > With that "solution" you've only added a new problem: you
> > now need to advertise the new functions and advise users
> > to use them, not `length', in such a use case.  Which
> > means you still have the need to identify the relevant use
> > cases, which means teach them about the `length' gotcha
> > (or hope they follow advice without understanding).  IOW,
> > now you have 2 problems...
> 
> Users certainly do need to know the performance cost of the functions
> that they use. But they also need alternatives. If (> (length list) n)
> is a trap for new players, then document it as so _and_ mention that
> there is a specific function that can be used to avoid the trap. But
> it's also worth mentioning that maybe the code should use a vector
> instead of a list, if the length is so important.

I spoke to that (e.g. doc guidance) a bit already:

https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg01757.html

And as I said, `length' is not so special in this regard.
`map', `dolist', and others also provide the same rope to
hang yourself with.

Learning to `throw' out of a list traversal (or whatever)
when you can tell it's time to quit is a _general_
solution/idiom - good to know about even if it's not
always the most appropriate.  That should be taught in
the manuals (in this general don't-continue-needlessly
context), even if many prefer things like `cl-loop'.

There are no specific functions that can be used to avoid
the trap.  Not in general.  Code that DTRT in any given
context can be short, sweet, and clear.  I see no help
offered by `length<' & compagnie.

And if the list in question is short, and the context is
not performance-critical (e.g. tight loop that's important),
then there may be no reason to bother about not traversing
it entirely.  IOW, this stuff is best considered case by
case.  Lisp already has all that's needed to create clear
code that does what one wants AND conveys to human readers
what's done and why. 

> Also, as was pointed out, this very thing happens 735 times in the Emacs
> lisp codebase. Probably most of those have no great performance impact,
> but it's a good observation.

If a given case has no performance impact, then it's
maybe better NOT to provide code that might give the
impression that we're trying to avoid a particular
performance penalty.  Of course in middle cases, which
might not be obvious to a human reader, we may need to
make things clear explicitly.

I wouldn't be in favor of systematically avoiding use
of `length', as if all uses are poisonous.  That would
almost be akin to wrapping all uses of `dolist' in a
`catch'.  It sends human readers the wrong message.
When it's important to avoid traversing more than
necessary, make that clear.  Avoiding it _always_ makes
it less clear when it's actually needed, not more.

(Just one opinion.)

RE: lengths and stuff

[Tomas Hlavaty]

On Sat 26 Dec 2020 at 21:23, Drew Adams <drew.adams@oracle.com> wrote:
> And as I said, `length' is not so special in this regard.  `map',
> `dolist', and others also provide the same rope to hang yourself with.

length is different than map and dolist.

length is about a property of a list, namely about number of items.

map and dolist are about doing something with items of list.

Using length in a predicate is yet completely different and most likely
bad because to answer the predicate, traversing the whole list is wasted
time and energy.

> There are no specific functions that can be used to avoid
> the trap.

There are not, but there could be.

> I see no help offered by `length<' & compagnie.

The idea is that the intent is expressed in a way that can _guarantee_
that useless length computation is avoided.

> And if the list in question is short, and the context is
> not performance-critical (e.g. tight loop that's important),
> then there may be no reason to bother about not traversing
> it entirely.  IOW, this stuff is best considered case by
> case.  Lisp already has all that's needed to create clear
> code that does what one wants AND conveys to human readers
> what's done and why.

In theory.  In reality, look at emacs code.  The new predicates will
allow not worrying about the trap and be sure that it is not there.  And
if somebody falls in the trap again, the new predicates will make it
easy to fix, simply by search and replace.

> If a given case has no performance impact, then it's
> maybe better NOT to provide code that might give the
> impression that we're trying to avoid a particular
> performance penalty.  Of course in middle cases, which
> might not be obvious to a human reader, we may need to
> make things clear explicitly.

But how do you know if it has or has not performance impact unless you
investigate each case?

With the new predicates, you do not need to investigate each case
because it will be taken care automatically.

> I wouldn't be in favor of systematically avoiding use
> of `length', as if all uses are poisonous.

In fact, it kind of is, especially when used in a predicate.

> That would almost be akin to wrapping all uses of `dolist' in a
> `catch'.

Why?  That does not make sense.

RE: lengths and stuff

[Drew Adams]

> > And as I said, `length' is not so special in this regard.  `map',
> > `dolist', and others also provide the same rope to hang yourself with.
> 
> length is different than map and dolist.

Everything that's not the same is different.

> length is about a property of a list, namely about number of items.
> map and dolist are about doing something with items of list.

That's a quibble.  Length is about doing something
with the list elements: counting them.  It's no more
about a property of a list than is a function that
checks all the element types or, like `member',
finds an element that satisfies some condition.

> Using length in a predicate is yet completely different and most likely
> bad because to answer the predicate, traversing the whole list is wasted
> time and energy.

(lambda (xs) (= (length xs) 25))  ; need to count elts

> > There are no specific functions that can be
> > used to avoid the trap.
> 
> There are not, but there could be.

No, not completely.  The gotcha is much more general
than the cases that could be "fixed" using the
proposed predicates.

> > I see no help offered by `length<' & compagnie.
> 
> The idea is that the intent is expressed in a way that can _guarantee_
> that useless length computation is avoided.

There are plenty of other possibilities for uselessly
invoking `length'.  Probably the most typical one is
neglecting to find the length only once and save it
in a local variable.

How much existing code (probably/hopefully mostly
outside the core code) does that, instead of this?

(let ((len  (length xs))) ... len ...len ... len ...)

A quick grep won't find places where code unwisely instead
does ... (length xs) ... (length xs) ... (length xs).

My guess is that those oblivious to the problem/gotcha
do that much more often than they do a single `length'
in a predicate that doesn't logically need to traverse
the whole list.

The point is that it's possible to misuse `length'
(and `dolist' and `member' and ...).  And no creation
of `length<' etc. predicates helps.  It fact, it can
hurt, as I explained previously.
 
> > IOW, this stuff is best considered case by case.

> > If a given case has no performance impact, then it's
> > maybe better NOT to provide code that might give the
> > impression that we're trying to avoid a particular
> > performance penalty.  Of course in middle cases, which
> > might not be obvious to a human reader, we may need to
> > make things clear explicitly.
> 
> But how do you know if it has or has not performance impact unless you
> investigate each case?

See above - this is best done case by case.  As with
all attempts to improve performance.  Do it when it's
appropriate/needed.  If you don't know whether it's
needed then don't do it.  If it's really needed you'll
know or you'll find out.

Premature or otherwise misguided optimization essentially
works against Occam's razor.  Relevant/necessary
optimization is just the opposite: it applies Occam's
razor. 

> > I wouldn't be in favor of systematically avoiding use
> > of `length', as if all uses are poisonous.
> 
> In fact, it kind of is, especially when used in a predicate.

No, it kind of isn't.  Find the _actual_ places where
the core Emacs code is _really_ problematic.  See how
many there are, compared to that shotgun-blast `grep'.
Fix occurrences where the performance matters, i.e.,
those that are really problematic.  End of story.

`length<' & compagnie: YAGNI.

RE: lengths and stuff

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 10:52, Drew Adams <drew.adams@oracle.com> wrote:
>> Using length in a predicate is yet completely different and most
>> likely bad because to answer the predicate, traversing the whole list
>> is wasted time and energy.
>
> (lambda (xs) (= (length xs) 25))  ; need to count elts

Is that a joke?

The predicates were proposed to help programers avoid writing such bad
code.  And if somebody writes such bad code, it is almost trivial to fix
it with search and replace:

   "(= (length" -> "(length="
   "(< (length" -> "(length<"
   "(> (length" -> "(length>"
   "(/= (length" -> "(length/="
   "(<= (length" -> "(length<="
   "(>= (length" -> "(length>="

Also the "symmetry" (or exhaustiveness?) here is to assist in easily
fixing bad code with minimum changes.

Nothing of course helps to those who are determined to unneccessarily
count _all_ the elements of lists.

Re: lengths and stuff

[Jean Louis]

* Tomas Hlavaty <tom@logand.com> [2020-12-27 23:53]:
> On Sun 27 Dec 2020 at 10:52, Drew Adams <drew.adams@oracle.com> wrote:
> >> Using length in a predicate is yet completely different and most
> >> likely bad because to answer the predicate, traversing the whole list
> >> is wasted time and energy.
> >
> > (lambda (xs) (= (length xs) 25))  ; need to count elts
> 
> Is that a joke?
> 
> The predicates were proposed to help programers avoid writing such bad
> code.  And if somebody writes such bad code, it is almost trivial to fix
> it with search and replace:
> 
>    "(= (length" -> "(length="
>    "(< (length" -> "(length<"
>    "(> (length" -> "(length>"
>    "(/= (length" -> "(length/="
>    "(<= (length" -> "(length<="
>    "(>= (length" -> "(length>="
> 
> Also the "symmetry" (or exhaustiveness?) here is to assist in easily
> fixing bad code with minimum changes.
> 
> Nothing of course helps to those who are determined to unneccessarily
> count _all_ the elements of lists.

May I understand if that proposal is to implement it in C or in Lisp?
Does that mean when (length< list-1 10) is implemented in C it would
become faster than: (< (length list-1) 10) ?

Or is that proposal to make Lisp functions like:

(defun length< (list n)
  (when (< (length list) n)
  t))

Re: lengths and stuff

[Eric Abrahamsen]

Jean Louis <bugs@gnu.support> writes:

> * Tomas Hlavaty <tom@logand.com> [2020-12-27 23:53]:
>> On Sun 27 Dec 2020 at 10:52, Drew Adams <drew.adams@oracle.com> wrote:
>> >> Using length in a predicate is yet completely different and most
>> >> likely bad because to answer the predicate, traversing the whole list
>> >> is wasted time and energy.
>> >
>> > (lambda (xs) (= (length xs) 25))  ; need to count elts
>> 
>> Is that a joke?
>> 
>> The predicates were proposed to help programers avoid writing such bad
>> code.  And if somebody writes such bad code, it is almost trivial to fix
>> it with search and replace:
>> 
>>    "(= (length" -> "(length="
>>    "(< (length" -> "(length<"
>>    "(> (length" -> "(length>"
>>    "(/= (length" -> "(length/="
>>    "(<= (length" -> "(length<="
>>    "(>= (length" -> "(length>="
>> 
>> Also the "symmetry" (or exhaustiveness?) here is to assist in easily
>> fixing bad code with minimum changes.
>> 
>> Nothing of course helps to those who are determined to unneccessarily
>> count _all_ the elements of lists.
>
> May I understand if that proposal is to implement it in C or in Lisp?
> Does that mean when (length< list-1 10) is implemented in C it would
> become faster than: (< (length list-1) 10) ?
>
> Or is that proposal to make Lisp functions like:
>
> (defun length< (list n)
>   (when (< (length list) n)
>   t))

They're already implemented in Emacs master, and they're in C. As I
understand it, one of the main advantages (beyond being simply faster,
possibly) is that they return early: if all you want to do is check if a
list has more than 2 elements, you don't have to calculate the whole
length, you can return t once you've found the third element.

Emacs Survey: Toolbars

[Lars Ingebrigtsen]

In that mega thread about modernising Emacs, there was a lot of talk
about getting more data about how people use Emacs, and then...  do
something accordingly.

Behold: https://emacssurvey.org/2020/

So here's the first thread about actionable takeaways from the survey.
(Consider all arguments about the survey not being representative as
having been made already.)

Of 7.3K respondents, 5K disable toolbars, which is more than two
thirds.  So perhaps toolbars should default to off?  I know toolbars
were all the rage in the 90s, but that's apparently not the case now.

Opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Christopher Dimech]

It concludes that besides Emacs, writers are the next group of people who make extensive
use of Emacs.  One consideration is to improve and enhance tools for writers.  Special
functionality for writers are Org-Mode, Texinfo, Org-Capture, Calendar, Agenda, Diary.

Whilst the last few are of minor interest to programmers, they have value for writers.
Another area is Accessibility.

---------------------
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy


> Sent: Tuesday, December 15, 2020 at 6:30 AM
> From: "Lars Ingebrigtsen" <larsi@gnus.org>
> To: emacs-devel@gnu.org
> Subject: Emacs Survey: Toolbars
>
> In that mega thread about modernising Emacs, there was a lot of talk
> about getting more data about how people use Emacs, and then...  do
> something accordingly.
>
> Behold: https://emacssurvey.org/2020/
>
> So here's the first thread about actionable takeaways from the survey.
> (Consider all arguments about the survey not being representative as
> having been made already.)
>
> Of 7.3K respondents, 5K disable toolbars, which is more than two
> thirds.  So perhaps toolbars should default to off?  I know toolbars
> were all the rage in the 90s, but that's apparently not the case now.
>
> Opinions?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>
>

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Christopher Dimech <dimech@gmx.com> writes:

> It concludes that besides Emacs, writers are the next group of people
> who make extensive use of Emacs.

I put the word "Toolbars" in the subject of this message because it's
about toolbars.  If you want to discuss other issues, I suggest you post
about that elsewhere.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Jean Louis]

LaTeX and similar also for researchers, writers

On December 15, 2020 5:57:55 AM UTC, Christopher Dimech <dimech@gmx.com> wrote:
>It concludes that besides Emacs, writers are the next group of people
>who make extensive
>use of Emacs.  One consideration is to improve and enhance tools for
>writers.  Special
>functionality for writers are Org-Mode, Texinfo, Org-Capture, Calendar,
>Agenda, Diary.
>
>Whilst the last few are of minor interest to programmers, they have
>value for writers.
>Another area is Accessibility.
>
>---------------------
>Christopher Dimech
>General Administrator - Naiad Informatics - GNU Project
>(Geocomputation)
>- Geophysical Simulation
>- Geological Subsurface Mapping
>- Disaster Preparedness and Mitigation
>- Natural Resource Exploration and Production
>- Free Software Advocacy
>
>
>> Sent: Tuesday, December 15, 2020 at 6:30 AM
>> From: "Lars Ingebrigtsen" <larsi@gnus.org>
>> To: emacs-devel@gnu.org
>> Subject: Emacs Survey: Toolbars
>>
>> In that mega thread about modernising Emacs, there was a lot of talk
>> about getting more data about how people use Emacs, and then...  do
>> something accordingly.


Jean

Re: Emacs Survey: Toolbars

[Clément Pit-Claudel]

On 12/15/20 12:30 AM, Lars Ingebrigtsen wrote:
> Of 7.3K respondents, 5K disable toolbars, which is more than two
> thirds.  So perhaps toolbars should default to off?  I know toolbars
> were all the rage in the 90s, but that's apparently not the case now.
> 
> Opinions?

2¢: keep them, though with prettier icons.  It's trivial to disable them, but it's not trivial to discover that they exist if they are disabled by default.
(FWIW, this is a general philosophy: I think Emacs should ship with a lot more stuff enabled by default, maybe with a spartan-mode to revert to the current defaults.)

Re: Emacs Survey: Toolbars

[Thibaut Verron]

I agree with Clément, for a total of 4 cents.

Also, I don't think that there is a clear majority of users disabling
the toolbar: instead, it looks like a majority of the respondents
(which do not necessarily form a representative sample) disable all
three bars and the splash screen, with a few disabling only the
toolbar. So if anything, the take-away is that it's not a
one-size-fits-all situation.

On the topic of enabling/disabling ui elements, I'm curious about the
visible-bell answer. Could it be that the question asked if they
disabled the visible bell, to which the logical answer for those
setting 'visible-bell to t (in order to disable the audible bell) is
no. In this case, the only yes would be users either disabling all
bells, or keeping the default bell AND knowing about it.

It would be interesting to know how many users would want to disable
the bell altogether if they knew that it is possible.



2020-12-15 7:24 UTC+01:00, Clément Pit-Claudel <cpitclaudel@gmail.com>:
> On 12/15/20 12:30 AM, Lars Ingebrigtsen wrote:
>> Of 7.3K respondents, 5K disable toolbars, which is more than two
>> thirds.  So perhaps toolbars should default to off?  I know toolbars
>> were all the rage in the 90s, but that's apparently not the case now.
>>
>> Opinions?
>
> 2¢: keep them, though with prettier icons.  It's trivial to disable them,
> but it's not trivial to discover that they exist if they are disabled by
> default.
> (FWIW, this is a general philosophy: I think Emacs should ship with a lot
> more stuff enabled by default, maybe with a spartan-mode to revert to the
> current defaults.)
>
>
>

Re: Emacs Survey: Toolbars

[Stephen Leake]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 12/15/20 12:30 AM, Lars Ingebrigtsen wrote:
>> Of 7.3K respondents, 5K disable toolbars, which is more than two
>> thirds.  So perhaps toolbars should default to off?  I know toolbars
>> were all the rage in the 90s, but that's apparently not the case now.
>> 
>> Opinions?
>
> 2¢: keep them, though with prettier icons. It's trivial to disable
> them, but it's not trivial to discover that they exist if they are
> disabled by default.

+1
 
> (FWIW, this is a general philosophy: I think Emacs should ship with a
> lot more stuff enabled by default, maybe with a spartan-mode to revert
> to the current defaults.)

That works for me as well.

Lots of eye candy by default to seduce new users, followed by easy ways
to configure the UI for higher productivity (which is why I turn off the
toolbar; keystrokes are more efficient than mouse movements, and this
gives more screen area for text).

-- 
-- Stephe

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 8:06 PM
> From: "Stephen Leake" <stephen_leake@stephe-leake.org>
> To: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Clément Pit-Claudel <cpitclaudel@gmail.com> writes:
> 
> > On 12/15/20 12:30 AM, Lars Ingebrigtsen wrote:
> >> Of 7.3K respondents, 5K disable toolbars, which is more than two
> >> thirds.  So perhaps toolbars should default to off?  I know toolbars
> >> were all the rage in the 90s, but that's apparently not the case now.
> >> 
> >> Opinions?
> >
> > 2¢: keep them, though with prettier icons. It's trivial to disable
> > them, but it's not trivial to discover that they exist if they are
> > disabled by default.
> 
> +1
>  
> > (FWIW, this is a general philosophy: I think Emacs should ship with a
> > lot more stuff enabled by default, maybe with a spartan-mode to revert
> > to the current defaults.)
> 
> That works for me as well.
> 
> Lots of eye candy by default to seduce new users, followed by easy ways
> to configure the UI for higher productivity (which is why I turn off the
> toolbar; keystrokes are more efficient than mouse movements, and this
> gives more screen area for text).

Spot on.  We can then just use emacs modes to switch.  New users will not need to do anything,
whilst experienced users can change modes.  The problem that most computer users do not use
Gnu is because most computers don't come with a Gnu System Pre-Installed.

Do people ordinarily change much on their phones, car, etc... No.  What we offer is that    
if you want change and have the skills (or can get someone with the appropriate skills)
you are in a position to do so.  But do not give new users more problems by demanding they
use the manual and learn elisp to customise the operation of emacs.  Rather, the Emacs Mantra should
be:

------- Emacs Mantra -------
Those with skills have the possibility to adapt emacs to their needs, once they read the manual
and learn elisp programming.   

 
> -- 
> -- Stephe
> 
>

Re: Emacs Survey: Toolbars

[Christopher Dimech]

Accessibility Tools must function by default.  Then one can make changes if they want to.
How can a person with certain limitations use free software when Emacs Accessibility Tools 
gets disabled by default???

This is a general introspection not only focused on Emacs.  But Emacs developers must 
remember these things if they want to be considered as serious people.

---------------------
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy


> Sent: Tuesday, December 15, 2020 at 8:06 PM
> From: "Stephen Leake" <stephen_leake@stephe-leake.org>
> To: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Clément Pit-Claudel <cpitclaudel@gmail.com> writes:
> 
> > On 12/15/20 12:30 AM, Lars Ingebrigtsen wrote:
> >> Of 7.3K respondents, 5K disable toolbars, which is more than two
> >> thirds.  So perhaps toolbars should default to off?  I know toolbars
> >> were all the rage in the 90s, but that's apparently not the case now.
> >> 
> >> Opinions?
> >
> > 2¢: keep them, though with prettier icons. It's trivial to disable
> > them, but it's not trivial to discover that they exist if they are
> > disabled by default.
> 
> +1
>  
> > (FWIW, this is a general philosophy: I think Emacs should ship with a
> > lot more stuff enabled by default, maybe with a spartan-mode to revert
> > to the current defaults.)
> 
> That works for me as well.
> 
> Lots of eye candy by default to seduce new users, followed by easy ways
> to configure the UI for higher productivity (which is why I turn off the
> toolbar; keystrokes are more efficient than mouse movements, and this
> gives more screen area for text).
> 
> -- 
> -- Stephe
> 
>

Re: Emacs Survey: Toolbars

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

  > Accessibility Tools must function by default.

We were talking about the toolbar, so I am surprised to see reference
to "accessibility tools".  Can you make the connection relates?

   > if they want to be considered as serious people.

We don't make decisions based on how people might "consider" what
we decide to do.  However, you might be thinking of some concrete
advantage or disadvantage of deleting the toolbar.  That could be
important -- would you please spell it out?

-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Wednesday, December 16, 2020 at 6:43 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: cpitclaudel@gmail.com, stephen_leake@stephe-leake.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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. ]]]
>
>   > Accessibility Tools must function by default.
>
> We were talking about the toolbar, so I am surprised to see reference
> to "accessibility tools".  Can you make the connection relates?

>    > if they want to be considered as serious people.
>
> We don't make decisions based on how people might "consider" what
> we decide to do.  However, you might be thinking of some concrete
> advantage or disadvantage of deleting the toolbar.  That could be
> important -- would you please spell it out?

The toolbar can be made to be an accessibility tool for people experiencing pain
when performing keypresses.  If people can introduce a toolbar icon and associate
a keybinding with it, they would be able to use that with KMouseTool to perform
the icon press for them.  And with a virtual keyboard, they can operate KMouseTool
for typing.

> --
> 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: Emacs Survey: Toolbars

[Jean Louis]

Only small subset of users answered the survey. Emacs is used by much larger number of people. One can see that survey says that users who did answer the survey are on level higher.

If you disable the toolbar you are doing it for those who answered the survey, not for those coming to Emacs, larger number of users. 

If I rememberv well survey also shows that large number of users use it since shorter time like one year meaning that larger number of users drop in the first year. Finding that cause and improving there would keep those users.



On December 15, 2020 5:30:20 AM UTC, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>In that mega thread about modernising Emacs, there was a lot of talk
>about getting more data about how people use Emacs, and then...  do
>something accordingly.
>
>Behold: https://emacssurvey.org/2020/
>
>So here's the first thread about actionable takeaways from the survey.
>(Consider all arguments about the survey not being representative as
>having been made already.)
>
>Of 7.3K respondents, 5K disable toolbars, which is more than two
>thirds.  So perhaps toolbars should default to off?  I know toolbars
>were all the rage in the 90s, but that's apparently not the case now.
>
>Opinions?


Jean

Re: Emacs Survey: Toolbars

[Christopher Dimech]

It occurs to me that rather than enhancing emacs, we are regressing it.
What we need is better functionality for some users which is not about
enabling or disabling a long known feature.

As one can see, few users program in lisp.  Consequently, assuming
that people are knowledgeable about elisp programming is wrong.


> Sent: Tuesday, December 15, 2020 at 11:00 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Lars Ingebrigtsen" <larsi@gnus.org>, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Only small subset of users answered the survey. Emacs is used by much larger number of people. One can see that survey says that users who did answer the survey are on level higher.
>
> If you disable the toolbar you are doing it for those who answered the survey, not for those coming to Emacs, larger number of users.
>
> If I rememberv well survey also shows that large number of users use it since shorter time like one year meaning that larger number of users drop in the first year. Finding that cause and improving there would keep those users.
>
>
>
> On December 15, 2020 5:30:20 AM UTC, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> >In that mega thread about modernising Emacs, there was a lot of talk
> >about getting more data about how people use Emacs, and then...  do
> >something accordingly.
> >
> >Behold: https://emacssurvey.org/2020/
> >
> >So here's the first thread about actionable takeaways from the survey.
> >(Consider all arguments about the survey not being representative as
> >having been made already.)
> >
> >Of 7.3K respondents, 5K disable toolbars, which is more than two
> >thirds.  So perhaps toolbars should default to off?  I know toolbars
> >were all the rage in the 90s, but that's apparently not the case now.
> >
> >Opinions?
>
>
> Jean
>
>

Re: Emacs Survey: Toolbars

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

  > As one can see, few users program in lisp.  Consequently, assuming
  > that people are knowledgeable about elisp programming is wrong.

Indeed, we should not assume that Emacs users can write any Lisp code.

Are we doing that?  Where are we doing that?


-- 
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: Emacs Survey: Toolbars

[Philip K.]

Jean Louis <bugs@gnu.support> writes:

> Only small subset of users answered the survey. Emacs is used by much larger number of people. One can see that survey says that users who did answer the survey are on level higher.
>
> If you disable the toolbar you are doing it for those who answered the survey, not for those coming to Emacs, larger number of users. 
>
> If I rememberv well survey also shows that large number of users use
> it since shorter time like one year meaning that larger number of
> users drop in the first year. Finding that cause and improving there
> would keep those users.

I guess it would be interesting to also find out what the connection is
between newer users and toolbar usage. I personally think that the
menu-bar is more than enough (though also not necessary), and that the
toolbar is inefficient, and even if it were, it's underutilized.

People who use the TUI mode or "distributions" also usually don't have
to disable it, so that might also be a factor that has to be considered.

> On December 15, 2020 5:30:20 AM UTC, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>>In that mega thread about modernising Emacs, there was a lot of talk
>>about getting more data about how people use Emacs, and then...  do
>>something accordingly.
>>
>>Behold: https://emacssurvey.org/2020/
>>
>>So here's the first thread about actionable takeaways from the survey.
>>(Consider all arguments about the survey not being representative as
>>having been made already.)
>>
>>Of 7.3K respondents, 5K disable toolbars, which is more than two
>>thirds.  So perhaps toolbars should default to off?  I know toolbars
>>were all the rage in the 90s, but that's apparently not the case now.
>>
>>Opinions?
>
>
> Jean
>
>

-- 
	Philip K.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 6:07 PM
> From: "Philip K." <philipk@posteo.net>
> To: "Jean Louis" <bugs@gnu.support>
> Cc: "Lars Ingebrigtsen" <larsi@gnus.org>, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Jean Louis <bugs@gnu.support> writes:
>
> > Only small subset of users answered the survey. Emacs is used by much larger number of people. One can see that survey says that users who did answer the survey are on level higher.
> >
> > If you disable the toolbar you are doing it for those who answered the survey, not for those coming to Emacs, larger number of users.
> >
> > If I rememberv well survey also shows that large number of users use
> > it since shorter time like one year meaning that larger number of
> > users drop in the first year. Finding that cause and improving there
> > would keep those users.
>
> I guess it would be interesting to also find out what the connection is
> between newer users and toolbar usage. I personally think that the
> menu-bar is more than enough (though also not necessary), and that the
> toolbar is inefficient, and even if it were, it's underutilized.

The advantage of the menu-bar is that we can have the associated
keybindings displayed.  And that would be extremely useful for users.
They can use the menu to find the associated key binding.  Yet, the
advantage of finding the keybinding from the menu-bar is not fully
realised.  This is one thing that could help new users.  A serious
improvement would involve updating the keybinding strings in the
menu-bar according to what is specifically defined by the customisation
of the user.  Particularly for people not using a querty keyboard.
For instance, adapting keybindings for use with the Dvorak Keyboard
would be a significant improvement.


> People who use the TUI mode or "distributions" also usually don't have
> to disable it, so that might also be a factor that has to be considered.
>
> > On December 15, 2020 5:30:20 AM UTC, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> >>In that mega thread about modernising Emacs, there was a lot of talk
> >>about getting more data about how people use Emacs, and then...  do
> >>something accordingly.
> >>
> >>Behold: https://emacssurvey.org/2020/
> >>
> >>So here's the first thread about actionable takeaways from the survey.
> >>(Consider all arguments about the survey not being representative as
> >>having been made already.)
> >>
> >>Of 7.3K respondents, 5K disable toolbars, which is more than two
> >>thirds.  So perhaps toolbars should default to off?  I know toolbars
> >>were all the rage in the 90s, but that's apparently not the case now.
> >>
> >>Opinions?
> >
> >
> > Jean
> >
> >
>
> --
> 	Philip K.
>
>

RE: Emacs Survey: Toolbars

[Drew Adams]

> The advantage of the menu-bar is that we can have the associated
> keybindings displayed.  And that would be extremely useful for users.
> They can use the menu to find the associated key binding.  

Is there something stopping Emacs from including
a key binding in the mouseover help text (tooltip
or echo area, depending on `tooltip-mode')?

That doesn't happen now, but it could, couldn't it?

Re: RE: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 6:40 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>, "Philip K." <philipk@posteo.net>
> Cc: "Lars Ingebrigtsen" <larsi@gnus.org>, "Jean Louis" <bugs@gnu.support>, emacs-devel@gnu.org
> Subject: RE: Emacs Survey: Toolbars
>
> > The advantage of the menu-bar is that we can have the associated
> > keybindings displayed.  And that would be extremely useful for users.
> > They can use the menu to find the associated key binding.
>
> Is there something stopping Emacs from including
> a key binding in the mouseover help text (tooltip
> or echo area, depending on `tooltip-mode')?
>
> That doesn't happen now, but it could, couldn't it?

That would appreciated by new users as they would have a convenient
and intuitive way to know the key binding.  This without having
to use keybinding ("C-h b", "C-h k", "C-h f") to find out about frequently
used keybindings.  Immediately getting to use  ("C-h b", "C-h k", "C-h f")
can be overwhelming to new users, particularly for school aged kids (aged 7-14).

Re: Emacs Survey: Toolbars

[Robert Pluim]

Drew Adams <drew.adams@oracle.com> writes:

>> The advantage of the menu-bar is that we can have the associated
>> keybindings displayed.  And that would be extremely useful for users.
>> They can use the menu to find the associated key binding.  
>
> Is there something stopping Emacs from including
> a key binding in the mouseover help text (tooltip
> or echo area, depending on `tooltip-mode')?
>
> That doesn't happen now, but it could, couldn't it?

In the toolbar? I see keybindings in mouseover text here in both
emacs-27 and master, on both GNU/Linux and macOS.

Robert

RE: Emacs Survey: Toolbars

[Drew Adams]

> > Is there something stopping Emacs from including
> > a key binding in the mouseover help text (tooltip
> > or echo area, depending on `tooltip-mode')?
> >
> > That doesn't happen now, but it could, couldn't it?
> 
> In the toolbar? I see keybindings in mouseover text here in both
> emacs-27 and master, on both GNU/Linux and macOS.

Great.  Yes, that was apparently added in Emacs 27.

[I'm still using Emacs 26.3 (can't use 27).]

dvorak users (was: Emacs Survey: Toolbars)

[andrés ramírez]

Hi Christopher.

>>>>> "Christopher" == Christopher Dimech <dimech@gmx.com> writes:


[...]


    Christopher> Particularly for people not using a querty keyboard.  For instance, adapting
    Christopher> keybindings for use with the Dvorak Keyboard would be a significant improvement.

I think for dvorak users a good tip is remapping C-t to C-x
--8<---------------cut here---------------start------------->8---
(defmacro wiki/bind-dvorak-helper (key fn) 
                    `(global-set-key (kbd ,key) ,(if (listp fn) fn `',fn)))
(wiki/bind-dvorak-helper "C-t" (lookup-key global-map (kbd "C-x")))
--8<---------------cut here---------------end--------------->8---

After doing above You would need to be careful when on dired. (C-t).

Also map C-c C-m as execute-extended-command
--8<---------------cut here---------------start------------->8---
(global-set-key (kbd "C-x C-m") 'execute-extended-command)
(global-set-key (kbd "\C-c\C-m") 'execute-extended-command) ; {from effective emacs}
--8<---------------cut here---------------end--------------->8---


[...]

Best Regards

Re: dvorak users (was: Emacs Survey: Toolbars)

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 7:02 PM
> From: "andrés ramírez" <rrandresf@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Philip K." <philipk@posteo.net>, "Lars Ingebrigtsen" <larsi@gnus.org>, "Jean Louis" <bugs@gnu.support>, emacs-devel@gnu.org
> Subject: dvorak users (was: Emacs Survey: Toolbars)
>
> Hi Christopher.
> 
> >>>>> "Christopher" == Christopher Dimech <dimech@gmx.com> writes:
> 
> 
> [...]
> 
> 
>     Christopher> Particularly for people not using a querty keyboard.  For instance, adapting
>     Christopher> keybindings for use with the Dvorak Keyboard would be a significant improvement.
> 
> I think for dvorak users a good tip is remapping C-t to C-x
> --8<---------------cut here---------------start------------->8---
> (defmacro wiki/bind-dvorak-helper (key fn) 
>                     `(global-set-key (kbd ,key) ,(if (listp fn) fn `',fn)))
> (wiki/bind-dvorak-helper "C-t" (lookup-key global-map (kbd "C-x")))
> --8<---------------cut here---------------end--------------->8---
> 
> After doing above You would need to be careful when on dired. (C-t).
> 
> Also map C-c C-m as execute-extended-command
> --8<---------------cut here---------------start------------->8---
> (global-set-key (kbd "C-x C-m") 'execute-extended-command)
> (global-set-key (kbd "\C-c\C-m") 'execute-extended-command) ; {from effective emacs}
> --8<---------------cut here---------------end--------------->8---

Quite correct Mr. Ramírez.  The important thing for Productivity and the eradication of
Repetitive Strain Injury is not the keybinding, but the keyboard setup.
 
> 
> [...]
> 
> Best Regards
>

Re: dvorak users (was: Emacs Survey: Toolbars)

[Ricardo Wurmus]

andrés ramírez <rrandresf@gmail.com> writes:

> Hi Christopher.
>
>>>>>> "Christopher" == Christopher Dimech <dimech@gmx.com> writes:
>
>
> [...]
>
>
>     Christopher> Particularly for people not using a querty keyboard.  For instance, adapting
>     Christopher> keybindings for use with the Dvorak Keyboard would be a significant improvement.
>
> I think for dvorak users a good tip is remapping C-t to C-x
> --8<---------------cut here---------------start------------->8---
> (defmacro wiki/bind-dvorak-helper (key fn) 
>                     `(global-set-key (kbd ,key) ,(if (listp fn) fn `',fn)))
> (wiki/bind-dvorak-helper "C-t" (lookup-key global-map (kbd "C-x")))
> --8<---------------cut here---------------end--------------->8---

Another global solution is this:

  (define-key key-translation-map [?\C-x] [?\C-t])
  (define-key key-translation-map [?\C-t] [?\C-x])

I’ve been using this for many years.

-- 
Ricardo

Re: Emacs Survey: Toolbars

[Eric S Fraga]

Although I disabled the toolbar when it first appeared (in the dim and
distant past), I think it's a good idea to leave them on by
default.  They are easy enough to disable and provide help for the true
neophyte.  In fact, learning how to disable the toolbar is probably a
good first exercise in customizing your Emacs!

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4 on Debian bullseye/sid

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> They are easy enough to disable and provide help for the true
> neophyte.

We have no data to support that.

> In fact, learning how to disable the toolbar is probably a
> good first exercise in customizing your Emacs!

I don't think that's a good argument for having a GUI element that few
people like, and which may well be discouraging people from using Emacs
at all (because it looks useless and out of touch).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Eric S Fraga]

Okay.  I'm not really bothered either way!
-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4 on Debian bullseye/sid

Re: Emacs Survey: Toolbars

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> They are easy enough to disable and provide help for the true
>> neophyte.
>
> We have no data to support that.
>
>> In fact, learning how to disable the toolbar is probably a
>> good first exercise in customizing your Emacs!
>
> I don't think that's a good argument for having a GUI element that few
> people like,

We have no data to support that.

> and which may well be discouraging people from using Emacs
> at all (because it looks useless and out of touch).

We have no data to support that.

;-)

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> I don't think that's a good argument for having a GUI element that few
>> people like,
>
> We have no data to support that.

I know you're being funny, but: The only data we have does support that.

>> and which may well be discouraging people from using Emacs
>> at all (because it looks useless and out of touch).
>
> We have no data to support that.

I did, very carefully, not claim that we do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> I don't think that's a good argument for having a GUI element that few
>>> people like,
>>
>> We have no data to support that.
>
> I know you're being funny, but: The only data we have does support that.

"Only data" != "data reliable enough to support decissions".

>>> and which may well be discouraging people from using Emacs
>>> at all (because it looks useless and out of touch).
>>
>> We have no data to support that.
>
> I did, very carefully, not claim that we do.

At some point on the past it was decided that having a toolbar was a
good thing. Switching it off just because a very poorly executed survey
barely resembles a democratic vote on its utility, without revisiting
the original motivation, is questionable.

Really, this kind of decissions should be based on guidance by UI
experts. Sadly, it seems that we have none onboard, same as every other
Free or Open Source projects around (and even most propietary ones).
They are very scarce.

BTW, I disable the toolbar (and the menu) on my config.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 6:47 PM
> From: "Óscar Fuentes" <ofv@wanadoo.es>
> To: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Óscar Fuentes <ofv@wanadoo.es> writes:
> >
> >>> I don't think that's a good argument for having a GUI element that few
> >>> people like,
> >>
> >> We have no data to support that.
> >
> > I know you're being funny, but: The only data we have does support that.
> 
> "Only data" != "data reliable enough to support decissions".
> 
> >>> and which may well be discouraging people from using Emacs
> >>> at all (because it looks useless and out of touch).
> >>
> >> We have no data to support that.
> >
> > I did, very carefully, not claim that we do.
> 
> At some point on the past it was decided that having a toolbar was a
> good thing. Switching it off just because a very poorly executed survey
> barely resembles a democratic vote on its utility, without revisiting
> the original motivation, is questionable.
> 
> Really, this kind of decissions should be based on guidance by UI
> experts. Sadly, it seems that we have none onboard, same as every other
> Free or Open Source projects around (and even most propietary ones).
> They are very scarce.

I am!  Having worked in remote sensing applications for natural resource management,
and submarine surveillance (my current specialisation).  
 
> BTW, I disable the toolbar (and the menu) on my config.
> 
> 
>

Re: Emacs Survey: Toolbars

[Philip K.]

Óscar Fuentes <ofv@wanadoo.es> writes:

>>>> and which may well be discouraging people from using Emacs
>>>> at all (because it looks useless and out of touch).
>>>
>>> We have no data to support that.
>>
>> I did, very carefully, not claim that we do.
>
> At some point on the past it was decided that having a toolbar was a
> good thing. Switching it off just because a very poorly executed survey
> barely resembles a democratic vote on its utility, without revisiting
> the original motivation, is questionable.
>
> Really, this kind of decissions should be based on guidance by UI
> experts. Sadly, it seems that we have none onboard, same as every other
> Free or Open Source projects around (and even most propietary ones).
> They are very scarce.

Maybe I'm too cynical, but can a non-Emacs UI expert really help with
something as other-worldly as Emacs? And I don't even mean this in an
elitist way, just that it has so many conventions and usage-patterns
from parallel UI traditions, that it might seem easier to just start all
over (which I'm not advocating for).

> BTW, I disable the toolbar (and the menu) on my config.

-- 
	Philip K.

Re: Emacs Survey: Toolbars

[Jean Louis]

* Philip K. <philipk@posteo.net> [2020-12-15 21:49]:
> Óscar Fuentes <ofv@wanadoo.es> writes:
> > Really, this kind of decissions should be based on guidance by UI
> > experts. Sadly, it seems that we have none onboard, same as every other
> > Free or Open Source projects around (and even most propietary ones).
> > They are very scarce.
> 
> Maybe I'm too cynical, but can a non-Emacs UI expert really help with
> something as other-worldly as Emacs? And I don't even mean this in an
> elitist way, just that it has so many conventions and usage-patterns
> from parallel UI traditions, that it might seem easier to just start all
> over (which I'm not advocating for).

Usability advises by Nielsen can definitely help, see here the outline
of a test: https://www.nngroup.com/articles/usability-testing-101/

If we have clear proposal on testing, I can provide the test with 5
people around me and give you results, then few other people can test
other few people and provide results. Or one built-in usability survey
can be delivered with Emacs or answered straight by people from Help
menu. It does not cost more than effort, not money.

That would accumulate data over time to know what people need and want
and how to improve the interface.

Jean

Re: Emacs Survey: Toolbars

[Christopher Dimech]

Then make a specific emacs mailing list for the topic and take live statistics from there.

> Sent: Tuesday, December 15, 2020 at 8:02 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Philip K." <philipk@posteo.net>
> Cc: "Óscar Fuentes" <ofv@wanadoo.es>, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> * Philip K. <philipk@posteo.net> [2020-12-15 21:49]:
> > Óscar Fuentes <ofv@wanadoo.es> writes:
> > > Really, this kind of decissions should be based on guidance by UI
> > > experts. Sadly, it seems that we have none onboard, same as every other
> > > Free or Open Source projects around (and even most propietary ones).
> > > They are very scarce.
> > 
> > Maybe I'm too cynical, but can a non-Emacs UI expert really help with
> > something as other-worldly as Emacs? And I don't even mean this in an
> > elitist way, just that it has so many conventions and usage-patterns
> > from parallel UI traditions, that it might seem easier to just start all
> > over (which I'm not advocating for).
> 
> Usability advises by Nielsen can definitely help, see here the outline
> of a test: https://www.nngroup.com/articles/usability-testing-101/
> 
> If we have clear proposal on testing, I can provide the test with 5
> people around me and give you results, then few other people can test
> other few people and provide results. Or one built-in usability survey
> can be delivered with Emacs or answered straight by people from Help
> menu. It does not cost more than effort, not money.
> 
> That would accumulate data over time to know what people need and want
> and how to improve the interface.
> 
> Jean
> 
> 
>

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 7:48 PM
> From: "Philip K." <philipk@posteo.net>
> To: "Óscar Fuentes" <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> >>>> and which may well be discouraging people from using Emacs
> >>>> at all (because it looks useless and out of touch).
> >>>
> >>> We have no data to support that.
> >>
> >> I did, very carefully, not claim that we do.
> >
> > At some point on the past it was decided that having a toolbar was a
> > good thing. Switching it off just because a very poorly executed survey
> > barely resembles a democratic vote on its utility, without revisiting
> > the original motivation, is questionable.
> >
> > Really, this kind of decissions should be based on guidance by UI
> > experts. Sadly, it seems that we have none onboard, same as every other
> > Free or Open Source projects around (and even most propietary ones).
> > They are very scarce.
> 
> Maybe I'm too cynical, but can a non-Emacs UI expert really help with
> something as other-worldly as Emacs? And I don't even mean this in an
> elitist way, just that it has so many conventions and usage-patterns
> from parallel UI traditions, that it might seem easier to just start all
> over (which I'm not advocating for).

Now start all over, but transition certain modes, or write new modes.  
We should not be afraid to throw away old functionality if things get
better.  Ultimately, Richard Stallman started his grudge because using
the printer ended up not being convenient for him.

I do not see many with the Stallman's Approach - I can do better, I have the skills, and
I will write new code, from scratch if necessary.  Only after about 8 years of Gnu did we
start to see operational advantages.

This reminds me of Tevye in the village of Anatevka in the opening number
"Tradition" of the 1964 Broadway Musical.  Emacs must be for worldly people
today, as was being for done for worldly people in the 80's. 
 
> > BTW, I disable the toolbar (and the menu) on my config.
> 
> -- 
> 	Philip K.
> 
>

Re: Emacs Survey: Toolbars

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

  > Maybe I'm too cynical, but can a non-Emacs UI expert really help with
  > something as other-worldly as Emacs?

They might perhaps have some good advice for us.

-- 
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: Emacs Survey: Toolbars

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2020-12-15 18:44]:
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> >> I don't think that's a good argument for having a GUI element that few
> >> people like,
> >
> > We have no data to support that.
> 
> I know you're being funny, but: The only data we have does support
> that.

Majority of users for the survey, if I remember well, came from
Reddit. There was description where it was marketed mostly.

Thus survey is not general Emacs survey, it is survey of mostly Reddit
users who may be or probably are more skillful.

If it would be general Emacs survey with general group of users mixed
with beginners, intermediate and advanced users and they all say by
majority they need no tool bar that would be valid information.

It looks that it is just specific group of more than intermediate
users of Emacs that disable toolbar.

Re: Emacs Survey: Toolbars

[Adrien Brochard]

> Majority of users for the survey, if I remember well, came from
> Reddit. There was description where it was marketed mostly.
>
> Thus survey is not general Emacs survey, it is survey of mostly Reddit
> users who may be or probably are more skillful.

What makes you think that people coming from the Reddit channel are more
skillful? If someone googles an Emacs question, getting directed to
r/emacs and finding the survey there is pretty likely.

> If it would be general Emacs survey with general group of users mixed
> with beginners, intermediate and advanced users and they all say by
> majority they need no tool bar that would be valid information.
>
> It looks that it is just specific group of more than intermediate
> users of Emacs that disable toolbar.

You guys should look into weighting adjustment of the data if you think
a population is over-represented.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Sunday, December 20, 2020 at 9:53 AM
> From: "Adrien Brochard" <abrochard@gmx.com>
> To: "Jean Louis" <bugs@gnu.support>, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> > Majority of users for the survey, if I remember well, came from
> > Reddit. There was description where it was marketed mostly.
> >
> > Thus survey is not general Emacs survey, it is survey of mostly Reddit
> > users who may be or probably are more skillful.
>
> What makes you think that people coming from the Reddit channel are more
> skillful? If someone googles an Emacs question, getting directed to
> r/emacs and finding the survey there is pretty likely.
>
> > If it would be general Emacs survey with general group of users mixed
> > with beginners, intermediate and advanced users and they all say by
> > majority they need no tool bar that would be valid information.
> >
> > It looks that it is just specific group of more than intermediate
> > users of Emacs that disable toolbar.
>
> You guys should look into weighting adjustment of the data if you think
> a population is over-represented.

Shitty data obtained without care, attention, and skill is useless data.  Forget the weighting!

Re: Emacs Survey: Toolbars

[Dmitry Gutov]

Hi Christopher,

On 20.12.2020 06:35, Christopher Dimech wrote:
> Shitty data obtained without care, attention, and skill is useless data.  Forget the weighting!

Please behave in a more civil matter here.

Also check out https://www.gnu.org/philosophy/kind-communication.html

Re: Emacs Survey: Toolbars

[Christopher Dimech]

Statistics give people the starting point to delve into that evidence and see if the arguments
hold together.  Reality must come before public relations for nature cannot be fooled.
I am one of those people discouraged from participating in Gnu development not because of
certain patterns of communication, but of certain patterns of working.
Fluttering Kind Communication Guidelines won't help.


---------------------
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy


> Sent: Sunday, December 20, 2020 at 7:14 PM
> From: "Dmitry Gutov" <dgutov@yandex.ru>
> To: "Christopher Dimech" <dimech@gmx.com>, "Adrien Brochard" <abrochard@gmx.com>
> Cc: "Jean Louis" <bugs@gnu.support>, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Hi Christopher,
>
> On 20.12.2020 06:35, Christopher Dimech wrote:
> > Shitty data obtained without care, attention, and skill is useless data.  Forget the weighting!
>
> Please behave in a more civil matter here.
>
> Also check out https://www.gnu.org/philosophy/kind-communication.html
>

Re: Emacs Survey: Toolbars

[Gregory Heytings via Emacs development discussions.]

Christopher Dimech:
>
> Shitty data obtained without care, attention, and skill is useless data. 
> Forget the weighting!
>

As the saying goes: "Criticism is easy, and art is difficult."  Could you 
please create and conduct a "good" survey, according to your criteria of 
"good"?  Or at least enlighten us, poor mortals, and explain what should 
have been done, and how?

Re: Emacs Survey: Toolbars

[Christopher Dimech]

That was a criticism on using weighting to account for missing data.  Weighting is
customarily used to reduce noise levels or as a sparsity constraint.  One possibility
would be a live survey (on the emacs website, a mailing list, ...).  Apologies if
the comment was too harsh.  The basic criticism has been that it favoured experienced
users.  Another way is to have multiple surveys based on emacs use experience, and then
normalise the results between the different experience levels.  In that way things
won't get skewed.

I would think that if there are competing views, we must not favour one or the other,
but consider them equally valid.  It would then be simply a question of priority or
perhaps measured on difficulty.  There is use for toolbars and should not be discounted.
Another way is to isolate functionality so those who want to use then can install a package.

Ultimately, it is for the maintainers and contributors to decide.  There are many books on
statistical inference.   A popular technique is to divide the data into groups followed by
a data representation strategy based on the most significant clusters.  One can also study
correlations between groups as being statistically significant.

> Sent: Tuesday, December 22, 2020 at 4:28 PM
> From: "Gregory Heytings via Emacs development discussions." <emacs-devel@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
>
> Christopher Dimech:
> >
> > Shitty data obtained without care, attention, and skill is useless data.
> > Forget the weighting!
> >
>
> As the saying goes: "Criticism is easy, and art is difficult."  Could you
> please create and conduct a "good" survey, according to your criteria of
> "good"?  Or at least enlighten us, poor mortals, and explain what should
> have been done, and how?
>
>

Re: Emacs Survey: Toolbars

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-12-22 15:23]:
> That was a criticism on using weighting to account for missing data.  Weighting is
> customarily used to reduce noise levels or as a sparsity constraint.  One possibility
> would be a live survey (on the emacs website, a mailing list, ...).

A built-in Emacs opinion poll sent by email in form of LISP data that
may be automatically evaluated would create better data on what people
wish and want, or what is more usable or not usable.

But even more usable would be simple Nielssen usability test:
https://www.nngroup.com/articles/usability-testing-101/

Jean

Re: Emacs Survey: Toolbars

[Jean Louis]

* Gregory Heytings via "Emacs development discussions. <emacs-devel@gnu.org> [2020-12-22 13:59]:
> 
> Christopher Dimech:
> > 
> > Shitty data obtained without care, attention, and skill is useless data.
> > Forget the weighting!
> > 
> 
> As the saying goes: "Criticism is easy, and art is difficult."  Could you
> please create and conduct a "good" survey, according to your criteria of
> "good"?  Or at least enlighten us, poor mortals, and explain what should
> have been done, and how?

Data may be obtained with care, attention and skill and still be
misleading.

That there are good intentions with the survey, I have no doubts.

On how results were presented and how survey has been conducted I have
no doubt that author lacks the skill on the specific subject of making
an opinion poll. 

I have no doubts that author of the survey did conduct the survey,
connected websites together and made some marketing for people to
place their polls. And I have no doubt on his other skills,
programming, using mathematics, and I did not review the way of
counting, but I would not doubt on the manner of counting statistics
at this moment.

Emacs survey has a lot of misleading information that was already
mentioned here.

Major misleading information is the difference between general survey
and specific survey that relates to a subset of people from specific
groups of people.

Then we come here to discuss the toolbar that only a subset of people
from specific groups of people said something about that. I do not
agree that "any data is better than no data". The information may be
useful but due to its presentation it may be even more misleading than
useful.

When one says it is "Emacs Survey" I do not see it and do not
understand it by such general term.

As one may see on this picture of the survey in question this survey
represents 54.1% of people comming exclusively from Reddit and Hacker
News, then comes 7.8% Twitter. Majority of people 61.9% answering the
survey are groups coming from Reddit, Hacker news and Twitter users.
https://emacssurvey.org/2020/how-did-you-hear-about-this-survey.svg

Better would be to say that it is Emacs Survey that represents almost
62% of Emacs users coming from Reddit, Hacker News and Twitter.

One may see here that 1.4% of users answered the survey by email:
https://emacssurvey.org/2020/submissions-medium.svg

There are 7344 total responses.

1.4% of 7344 is 102+ users (more than 102 due to floating
point).

Maybe those users did not want to submit the online form as they did
not want to use non-free Javascript? But maybe those users did not
want to submit as they wanted to express themselves better by using
the Org file sent by email? We do not know why, but we can assume that
1.4% did not want to submit the form online.

We may compare data, we could take the Debian popularity contest:
https://qa.debian.org/popcon.php?package=popularity-contest
where recent data says that 200504 people installed the package
`popularity-contest' that counts which other packages are installed on
the system.

Then we may look into the subset of those 200504 Debian users who
installed Emacs: https://qa.debian.org/popcon.php?package=emacs

To me it looks like about 14,000 users installed Emacs on their Debian
GNU/Linux system. That amounts to some 6.98% of 200504 users who use
the Debian popularity contest package.

As Ubuntu comes from Debian GNU/Linux some vague information says
there are 20 million Ubuntu users.

If we would follow the trend of 6.98% let us truncated it to 6% of
people using Emacs on Debian derivative distribution, that would
amount already to (* 20000000 0.06) 1,200,000 people using Emacs in
Ubuntu. https://ubuntu.com/blog/ubuntu-is-everywhere maybe this number
is larger or bigger, but it does give some traces on how to conclude
how many people are using Emacs.

This page says there must be 100+ millions of GNU/Linux users on
Desktop (not counting Android):
https://www.quora.com/How-many-Linux-users-are-there-in-the-world/answer/Juha-Kaskiharju

but I cannot know where and how information has been obtained:
https://www.netmarketshare.com/linux-market-share

If we do assume there are 100+ millions GNU/Linux users who use their
browser as that is how companies detect such users and that 6.98%
trend as established from Debian popularity contest uses Emacs than
that may amount to 6-7 millions of Emacs users.

If we now come back to those 1.4% that did not want to answer the
survey by using non-free Javascript, maybe the real amount of those
people, who did not see the survey, but would not answer the WWW
survey for some of not unknown reasons, is already (* 6980000 0.014)
97720 users.

Emacs survey of 62% of Emacs users coming from Reddit, Hacker News and
Twitter has shown that that subset of users being about 4340 users
would gladly answer the survey over WWW form, with or without
considering if they use free or non-free Javascript.

I am personally, not by mathematical estimation, thinking that 90,000
of Emacs users and more than that, would not answer the survey only
because of the non-free Javascript or because how survey was
conducted.

Now let us say we discuss of toolbars, we do not discuss of toolbars
for Emacs users. We discuss of the fact that 85.1% of users using
Reddit, Stackexchange and Twitter who answered the Emacs survey that
relates to 62% to those groups are disabling the toolbar.

MacOS users from the Emacs survey are 26.6% plus Windos 7.4%, total
being 34% among all Emacs survey users or 34% from 7000 amounting to
some 2380 users.

When considering then if toolbar shall be disabled, shall we also
consider are we disabling it for majority of GNU/Linux users, or for
majority of proprietary system users, or for those Emacs users who
never answered the survey due to not unknown reasons which may amount
to almost 100,000 but which user habits we do not know.

In general the survey results would be much more useful would we have
intersections of people by various characteristics. We do not have
intersections, though it could be possible to make such intersections
with the data at hand.

Then survey did not give the result if users would like by default the
toolbar to be disabled. As when user disables the toolbar it does not
mean user would like it by default to be disabled upon first
installation.

The Emacs survey we speak about is not general Emacs survey.

That is in my opinion major misconception that people will get as it
all sounds so much official with nice and shiny charts.

It is Emacs survey that represents for 62% those users coming from
Reddit, Stackexchange, Twitter and we do not know many of intersection
results as such are not presented on the website.

If one only looks at one chart, like on chart among Emacs Survey
representing 62% users from Reddit, Stackexchange, Twitter, then one
may draw conclusions which are counter useful to the real number of
Emacs users.

What would be useful to know for development could be interesections
of:

- users using Windows, using Emacs with daemon mode
- users using MacOS, using Emacs with daemon mode
- users using GNU/Linux, using Emacs with daemon mode

- users using Windows, using Emacs as GUI or terminal
- users using MacOS, using Emacs as GUI or terminal
- users using GNU/Linux, using Emacs as GUI or terminal

- users using Windows, disabling toolbar
- users using MacOS, disabling toolbar
- users using GNU/Linux, disabling toolbar

then again intersections for menu bar, splash screen, etc.

Taking just one chart and looking how 85.1% users disabled toolbar is
incorrect interpretation that there is something to be handled as that
data comes from specific groups of people.

One cannot even ask experienced user if the tool bar should be
disabled as that is misleading. One could only ask a very new user who
has never seen Emacs, by placing that user on the chair and showing
him Emacs interface and then asking him if the toolbar is useful or
not useful.

Make that a first question to 10 people who never used Emacs and then
see the result and compare it. I guess that 10 people would be enough,
Nielssen says 5 people are enough, and I understand his methodology.

It is thus in my opinion more productive and more useful to take those
5 people or make 3 groups or 5 groups of 5 people and place them in
front of Emacs to tell us if they find toolbar useful.

It is counter productive to make assumptions to disable toolbar
because users who already used Emacs probably for years disabled the
toolbar. They are not new users.

While they may tell that disabled toolbar for them is good, they
cannot tell that for new users for which toolbar would be disabled by
default, they are not qualified for that as they are not new users any
more.

Jean

Re: Emacs Survey: Toolbars

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

  > > Shitty data obtained without care, attention, and skill is useless data. 
  > > Forget the weighting!
  > >

  > As the saying goes: "Criticism is easy, and art is difficult."  Could you 
  > please create and conduct a "good" survey, according to your criteria of 
  > "good"?  Or at least enlighten us, poor mortals, and explain what should 
  > have been done, and how?

Please, everyone, let's discuss this without getting angry at each other.
That is very important!  We have to _work together_ to use the answers.

The survey does not have a reprepresentative sample, but that doesn't
mean it is useless.  I wouldn't attach significance to its precise
numbers, but even the rough quantities have something to teach us.

For instance, we know that lots of users don't want the toolbars,
but a substantial fraction do not turn them off.

If we want more precise figures, I've suggested how to get them.
But I contend that we can come up with approaches that will
to a good job for the various kinds of users we know exist,
without needing to know the precise size of each kind.
We need to be clever and try lots of options.

-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Wednesday, December 23, 2020 at 9:56 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Gregory Heytings" <ghe@sdf.org>
> Cc: dimech@gmx.com, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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. ]]]
>
>   > > Shitty data obtained without care, attention, and skill is useless data.
>   > > Forget the weighting!
>   > >
>
>   > As the saying goes: "Criticism is easy, and art is difficult."  Could you
>   > please create and conduct a "good" survey, according to your criteria of
>   > "good"?  Or at least enlighten us, poor mortals, and explain what should
>   > have been done, and how?
>
> Please, everyone, let's discuss this without getting angry at each other.
> That is very important!  We have to _work together_ to use the answers.
>
> The survey does not have a reprepresentative sample, but that doesn't
> mean it is useless.  I wouldn't attach significance to its precise
> numbers, but even the rough quantities have something to teach us.

People should not take offense on a description that defines how things
are.   When surveys are not representative of reality and we cannot attach
to them significance, it is disconcerting when the severe effects of that
are not being taken forward.

I remember criticising geologists interpreting seismic characteristics when
the geophysical image did not allow interpretations below a certain level of
resolution.  But they did that anyway.

A useful reading is "Command and Control: Nuclear Weapons, the Damascus Accident,
and the Illusion of Safety".  I am an adult living within the constraints
and responsibilities of society not a boy believing that everything is possible.


> For instance, we know that lots of users don't want the toolbars,
> but a substantial fraction do not turn them off.
>
> If we want more precise figures, I've suggested how to get them.
> But I contend that we can come up with approaches that will
> to a good job for the various kinds of users we know exist,
> without needing to know the precise size of each kind.
> We need to be clever and try lots of options.
>
> --
> 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: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Wednesday, December 23, 2020 at 9:56 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Gregory Heytings" <ghe@sdf.org>
> Cc: dimech@gmx.com, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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. ]]]
>
>   > > Shitty data obtained without care, attention, and skill is useless data.
>   > > Forget the weighting!
>   > >
>
>   > As the saying goes: "Criticism is easy, and art is difficult."  Could you
>   > please create and conduct a "good" survey, according to your criteria of
>   > "good"?  Or at least enlighten us, poor mortals, and explain what should
>   > have been done, and how?
>
> Please, everyone, let's discuss this without getting angry at each other.
> That is very important!  We have to _work together_ to use the answers.
>
> The survey does not have a reprepresentative sample, but that doesn't
> mean it is useless.  I wouldn't attach significance to its precise
> numbers, but even the rough quantities have something to teach us.
>
> For instance, we know that lots of users don't want the toolbars,
> but a substantial fraction do not turn them off.
>
> If we want more precise figures, I've suggested how to get them.
> But I contend that we can come up with approaches that will
> to a good job for the various kinds of users we know exist,
> without needing to know the precise size of each kind.
> We need to be clever and try lots of options.

Fully agree with that - doing a good job for the various kinds of users
we know 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: Emacs Survey: Toolbars

[Jean Louis]

* Adrien Brochard <abrochard@gmx.com> [2020-12-20 07:24]:
> > Majority of users for the survey, if I remember well, came from
> > Reddit. There was description where it was marketed mostly.
> > 
> > Thus survey is not general Emacs survey, it is survey of mostly Reddit
> > users who may be or probably are more skillful.
> 
> What makes you think that people coming from the Reddit channel are more
> skillful? If someone googles an Emacs question, getting directed to
> r/emacs and finding the survey there is pretty likely.

"who may be or probably", see above to understand the intended
meaning.

It is a survey that targeted intentionally or not intentionally just a
subset of Emacs users using Reddit and few other popular websites.

Those who speak about Emacs on reddit in my opinion are minimally
slightly advanced users, as they discuss about Emacs.

I was using Emacs for years without discussing with anybody. Debian
popularity contest says that there is much larger number of Emacs
users.

The true representative survey information could be obtained only
within Emacs itself under condition that survey is presented straight
to Emacs user.

Jean

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Sunday, December 20, 2020 at 4:27 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Adrien Brochard" <abrochard@gmx.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> * Adrien Brochard <abrochard@gmx.com> [2020-12-20 07:24]:
> > > Majority of users for the survey, if I remember well, came from
> > > Reddit. There was description where it was marketed mostly.
> > >
> > > Thus survey is not general Emacs survey, it is survey of mostly Reddit
> > > users who may be or probably are more skillful.
> >
> > What makes you think that people coming from the Reddit channel are more
> > skillful? If someone googles an Emacs question, getting directed to
> > r/emacs and finding the survey there is pretty likely.
>
> "who may be or probably", see above to understand the intended
> meaning.
>
> It is a survey that targeted intentionally or not intentionally just a
> subset of Emacs users using Reddit and few other popular websites.
>
> Those who speak about Emacs on reddit in my opinion are minimally
> slightly advanced users, as they discuss about Emacs.
>
> I was using Emacs for years without discussing with anybody. Debian
> popularity contest says that there is much larger number of Emacs
> users.
>
> The true representative survey information could be obtained only
> within Emacs itself under condition that survey is presented straight
> to Emacs user.

I wonder whether the survey stems from lack of vision of emacs admin and developers.
For instance, Gcc has a Development Plan.  Suggestions for changes to the plan are
discussed on the Gcc mailing list and can be approved or rejected by the Gcc Steering
Committee. How about Emacs?

> Jean

Re: Emacs Survey: Toolbars

[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 wonder whether the survey stems from lack of vision of emacs
  > admin and developers.  For instance, Gcc has a Development Plan.
  > Suggestions for changes to the plan are discussed on the Gcc
  > mailing list and can be approved or rejected by the Gcc Steering
  > Committee. How about Emacs?

GCC has many developers who are paid by various companies.
That makes it easier to make plans and actually carry them out.

The Emacs contributors are all volunteers, so we can't tell anyone
what to do.  We can only exhort and apply naked emotional pressure,
which works only sometimes.

I've been trying for more than 10 years to urge people to work toward
giving Emacs the document capabilities of a word processor, but I have
not convinced people to do this work.

-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Monday, December 21, 2020 at 11:17 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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 wonder whether the survey stems from lack of vision of emacs
>   > admin and developers.  For instance, Gcc has a Development Plan.
>   > Suggestions for changes to the plan are discussed on the Gcc
>   > mailing list and can be approved or rejected by the Gcc Steering
>   > Committee. How about Emacs?
>
> GCC has many developers who are paid by various companies.
> That makes it easier to make plans and actually carry them out.
>
> The Emacs contributors are all volunteers, so we can't tell anyone
> what to do.  We can only exhort and apply naked emotional pressure,
> which works only sometimes.

Perhaps not in all details, but at some level it would benefit to
consider an actual plan.  Else things move on quite haphazardly.
For instance, certain changes are better done in a sequence.
And if you are tackling a problem, you can consider tackling
a related one.

We could also motivate by offering small payments for solutions to
unresolved problems.  I am sure there are many whose professional
job is in computing and could get young people to work on some
challenging areas or get their interest in helping out if there was
a plan.

Most people I know don't know what to do or what problems are out there.

> I've been trying for more than 10 years to urge people to work toward
> giving Emacs the document capabilities of a word processor, but I have
> not convinced people to do this work.
>
> --
> 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: Emacs Survey: Toolbars

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-12-21 09:57]:
> > Sent: Monday, December 21, 2020 at 11:17 AM
> > From: "Richard Stallman" <rms@gnu.org>
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
> > Subject: Re: Emacs Survey: Toolbars
> >
> > [[[ 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 wonder whether the survey stems from lack of vision of emacs
> >   > admin and developers.  For instance, Gcc has a Development Plan.
> >   > Suggestions for changes to the plan are discussed on the Gcc
> >   > mailing list and can be approved or rejected by the Gcc Steering
> >   > Committee. How about Emacs?
> >
> > GCC has many developers who are paid by various companies.
> > That makes it easier to make plans and actually carry them out.
> >
> > The Emacs contributors are all volunteers, so we can't tell anyone
> > what to do.  We can only exhort and apply naked emotional pressure,
> > which works only sometimes.
> 
> Perhaps not in all details, but at some level it would benefit to
> consider an actual plan.  Else things move on quite haphazardly.
> For instance, certain changes are better done in a sequence.
> And if you are tackling a problem, you can consider tackling
> a related one.

There are many volunteer organizations where people make a plan of
action. Volunteer or not, it is not related to planning. Especially if
one wish to spare the time for developers it is better to have a
development plan.

It could be a simple list of most important issues to be handled for
Emacs.

When such list is published maybe more contributors could be drawn to
it.

And I see no reason why FSF donations could not be used to improve
developer's life.

Jean

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> Date: Mon, 21 Dec 2020 10:04:53 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: abrochard@gmx.com, rms@gnu.org, bugs@gnu.support, emacs-devel@gnu.org
> 
> There are many volunteer organizations where people make a plan of
> action. Volunteer or not, it is not related to planning. Especially if
> one wish to spare the time for developers it is better to have a
> development plan.
> 
> It could be a simple list of most important issues to be handled for
> Emacs.
> 
> When such list is published maybe more contributors could be drawn to
> it.

We have that: etc/TODO.  But that isn't a "plan" in any reasonable
sense of the word, it's just a list of useful features that we would
like to have at some point.  Sometimes, not very frequently, someone
comes and actually takes up one of those jobs.

But much more frequently, someone comes up with an implemented feature
and submits it for inclusion, and we usually accept it.  Since there's
no way to plan that in advance, almost all of Emacs development moves
by such submissions which no one planned in advance.

Frequent contributors to Emacs probably have their own personal plans,
and work according to them as their time permits.  But these personal
plans are almost never coordinated with anyone else.

I don't see how anything different from the above could ever work, as
long as the project continues to be a loosely coupled group of people
with very disparate interests.  (I also see nothing wrong in how we do
things, FWIW.)

Re: Emacs Survey: Toolbars

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-21 19:17]:
> > Date: Mon, 21 Dec 2020 10:04:53 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: abrochard@gmx.com, rms@gnu.org, bugs@gnu.support, emacs-devel@gnu.org
> > 
> > There are many volunteer organizations where people make a plan of
> > action. Volunteer or not, it is not related to planning. Especially if
> > one wish to spare the time for developers it is better to have a
> > development plan.
> > 
> > It could be a simple list of most important issues to be handled for
> > Emacs.
> > 
> > When such list is published maybe more contributors could be drawn to
> > it.
> 
> We have that: etc/TODO.  But that isn't a "plan" in any reasonable
> sense of the word, it's just a list of useful features that we would
> like to have at some point.  Sometimes, not very frequently, someone
> comes and actually takes up one of those jobs.
> 
> But much more frequently, someone comes up with an implemented feature
> and submits it for inclusion, and we usually accept it.  Since there's
> no way to plan that in advance, almost all of Emacs development moves
> by such submissions which no one planned in advance.
> 
> Frequent contributors to Emacs probably have their own personal plans,
> and work according to them as their time permits.  But these personal
> plans are almost never coordinated with anyone else.

It works amazingly by willingness and contribution.

> I don't see how anything different from the above could ever work, as
> long as the project continues to be a loosely coupled group of people
> with very disparate interests.  (I also see nothing wrong in how we do
> things, FWIW.)

What is in your opinion priority for Emacs?

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> Date: Mon, 21 Dec 2020 19:51:43 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org,
>   emacs-devel@gnu.org
> 
> What is in your opinion priority for Emacs?

That question is too general to be useful, sorry.  Emacs has a
gazillion different facets, and at least a dozen of fundamental
infrastructure features in very different domains.  There isn't, and
IMO cannot be, a single priority, and moreover, if we'd try to come up
with a priority list, we'd argue till the Second Coming without
reaching any agreement.

I also don't see any sense in trying to define such priorities, as
long as no one but myself will be following them.

Re: Emacs Survey: Toolbars

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-21 20:21]:
> > Date: Mon, 21 Dec 2020 19:51:43 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org,
> >   emacs-devel@gnu.org
> > 
> > What is in your opinion priority for Emacs?
> 
> That question is too general to be useful, sorry.  Emacs has a
> gazillion different facets, and at least a dozen of fundamental
> infrastructure features in very different domains.  There isn't, and
> IMO cannot be, a single priority, and moreover, if we'd try to come up
> with a priority list, we'd argue till the Second Coming without
> reaching any agreement.

Hahahahaa

Re: Emacs Survey: Toolbars

[Christopher Dimech]

One may is to categorise according to separate emacs structures.  Then
have some from each make a plan with a list of five things to do, and
about eight tickets to work on.  And so on.  A few people should come
together, each person focused on a particular thing and the team led
by Eli.  Just don't make it in an argumentative way.  Am quite sure that
notwithstanding disagreements, some tasks could need to be handled better,
and work could focus on that.  Then introduce just one or two hot topics
so that arguments can be managed better.  I would say that it is most likely
that areas of great controversy indicate that the various aspects of contention
have got to be tackled, rather than focusing on one to the detriment of the other.

1. Major Modes
2. Minor Modes
3. Performance
4. Org-Mode
5. Completion
6. User Interface



> Sent: Monday, December 21, 2020 at 11:28 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Eli Zaretskii" <eliz@gnu.org>
> Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> * Eli Zaretskii <eliz@gnu.org> [2020-12-21 20:21]:
> > > Date: Mon, 21 Dec 2020 19:51:43 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org,
> > >   emacs-devel@gnu.org
> > >
> > > What is in your opinion priority for Emacs?
> >
> > That question is too general to be useful, sorry.  Emacs has a
> > gazillion different facets, and at least a dozen of fundamental
> > infrastructure features in very different domains.  There isn't, and
> > IMO cannot be, a single priority, and moreover, if we'd try to come up
> > with a priority list, we'd argue till the Second Coming without
> > reaching any agreement.
>
> Hahahahaa
>

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> There isn't, and IMO cannot be, a single priority, and moreover, if
> we'd try to come up with a priority list, we'd argue till the Second
> Coming without reaching any agreement.

I take that as an invitation, and I think that, without a doubt, our top
priority should be finding a more modern default colour for the mode line.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Arthur Miller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> There isn't, and IMO cannot be, a single priority, and moreover, if
>> we'd try to come up with a priority list, we'd argue till the Second
>> Coming without reaching any agreement.
>
> I take that as an invitation, and I think that, without a doubt, our top
> priority should be finding a more modern default colour for the mode line.
I think it is more important to find more modern font fo the clock when
it is displayed on the mode line.

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 21 Dec 2020 19:03:00 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There isn't, and IMO cannot be, a single priority, and moreover, if
> > we'd try to come up with a priority list, we'd argue till the Second
> > Coming without reaching any agreement.
> 
> I take that as an invitation, and I think that, without a doubt, our top
> priority should be finding a more modern default colour for the mode line.

I disagree!  Let's argue.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Monday, December 21, 2020 at 10:50 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Jean Louis" <bugs@gnu.support>
> Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> > Date: Mon, 21 Dec 2020 19:51:43 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org,
> >   emacs-devel@gnu.org
> >
> > What is in your opinion priority for Emacs?
>
> That question is too general to be useful, sorry.  Emacs has a
> gazillion different facets, and at least a dozen of fundamental
> infrastructure features in very different domains.  There isn't, and
> IMO cannot be, a single priority, and moreover, if we'd try to come up
> with a priority list, we'd argue till the Second Coming without
> reaching any agreement.
>
> I also don't see any sense in trying to define such priorities, as
> long as no one but myself will be following them.

Could you then come up with your plan as per your decisions so others can see
what's happening with Emacs.  Emacs could need two other people who are skilled
enough.  People have got to understand this.  Although Eli is responsible
and dedicated to Emacs Development, there cannot be just one person fully immersed
in it.

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: Jean Louis <bugs@gnu.support>, abrochard@gmx.com, rms@gnu.org,
>  emacs-devel@gnu.org
> Date: Tue, 22 Dec 2020 00:37:26 +0100
> 
> > > What is in your opinion priority for Emacs?
> >
> > That question is too general to be useful, sorry.  Emacs has a
> > gazillion different facets, and at least a dozen of fundamental
> > infrastructure features in very different domains.  There isn't, and
> > IMO cannot be, a single priority, and moreover, if we'd try to come up
> > with a priority list, we'd argue till the Second Coming without
> > reaching any agreement.
> >
> > I also don't see any sense in trying to define such priorities, as
> > long as no one but myself will be following them.
> 
> Could you then come up with your plan as per your decisions so others can see
> what's happening with Emacs.

I don't think I understand what you mean here, sorry.

> Emacs could need two other people who are skilled
> enough.  People have got to understand this.  Although Eli is responsible
> and dedicated to Emacs Development, there cannot be just one person fully immersed
> in it.

I'm far from the only one who determines what developments are or will
be going on in Emacs.  Just look at "git log" and you will see that.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 22, 2020 at 8:53 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: abrochard@gmx.com, rms@gnu.org, bugs@gnu.support, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: Jean Louis <bugs@gnu.support>, abrochard@gmx.com, rms@gnu.org,
> >  emacs-devel@gnu.org
> > Date: Tue, 22 Dec 2020 00:37:26 +0100
> >
> > > > What is in your opinion priority for Emacs?
> > >
> > > That question is too general to be useful, sorry.  Emacs has a
> > > gazillion different facets, and at least a dozen of fundamental
> > > infrastructure features in very different domains.  There isn't, and
> > > IMO cannot be, a single priority, and moreover, if we'd try to come up
> > > with a priority list, we'd argue till the Second Coming without
> > > reaching any agreement.
> > >
> > > I also don't see any sense in trying to define such priorities, as
> > > long as no one but myself will be following them.
> >
> > Could you then come up with your plan as per your decisions so others can see
> > what's happening with Emacs.
>
> I don't think I understand what you mean here, sorry.
>
> > Emacs could need two other people who are skilled
> > enough.  People have got to understand this.  Although Eli is responsible
> > and dedicated to Emacs Development, there cannot be just one person fully immersed
> > in it.
>
> I'm far from the only one who determines what developments are or will
> be going on in Emacs.  Just look at "git log" and you will see that.

Do you like it how it is?  Have heard you say that ultimately you have to
do work, and when you ask for help nobody comes forward.

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: abrochard@gmx.com, rms@gnu.org, bugs@gnu.support, emacs-devel@gnu.org
> Date: Wed, 23 Dec 2020 02:32:09 +0100
> 
> > > Emacs could need two other people who are skilled
> > > enough.  People have got to understand this.  Although Eli is responsible
> > > and dedicated to Emacs Development, there cannot be just one person fully immersed
> > > in it.
> >
> > I'm far from the only one who determines what developments are or will
> > be going on in Emacs.  Just look at "git log" and you will see that.
> 
> Do you like it how it is?

It doesn't matter if I like it or not if I cannot change it.  Whatever
I thought I could change I already did, or at least tried.

> Have heard you say that ultimately you have to do work, and when you
> ask for help nobody comes forward.

Not always and with any issue, but sometimes, yes.

Still, Emacs development is determined by many more people, which is a
Good Thing.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Monday, December 21, 2020 at 10:21 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Eli Zaretskii" <eliz@gnu.org>
> Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> * Eli Zaretskii <eliz@gnu.org> [2020-12-21 19:17]:
> > > Date: Mon, 21 Dec 2020 10:04:53 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: abrochard@gmx.com, rms@gnu.org, bugs@gnu.support, emacs-devel@gnu.org
> > >
> > > There are many volunteer organizations where people make a plan of
> > > action. Volunteer or not, it is not related to planning. Especially if
> > > one wish to spare the time for developers it is better to have a
> > > development plan.
> > >
> > > It could be a simple list of most important issues to be handled for
> > > Emacs.
> > >
> > > When such list is published maybe more contributors could be drawn to
> > > it.
> >
> > We have that: etc/TODO.  But that isn't a "plan" in any reasonable
> > sense of the word, it's just a list of useful features that we would
> > like to have at some point.  Sometimes, not very frequently, someone
> > comes and actually takes up one of those jobs.
> >
> > But much more frequently, someone comes up with an implemented feature
> > and submits it for inclusion, and we usually accept it.  Since there's
> > no way to plan that in advance, almost all of Emacs development moves
> > by such submissions which no one planned in advance.
> >
> > Frequent contributors to Emacs probably have their own personal plans,
> > and work according to them as their time permits.  But these personal
> > plans are almost never coordinated with anyone else.
>
> It works amazingly by willingness and contribution.

> > I don't see how anything different from the above could ever work, as
> > long as the project continues to be a loosely coupled group of people
> > with very disparate interests.  (I also see nothing wrong in how we do
> > things, FWIW.)

There lies the problem.  The project cannot continue to be loosely coupled
with very disparate interests.  The major people involved should come together
as a team.  This means that they should spend some of their time looking at
the other interests.

There are several possibilities that can be used simultaneously

1. For every five aspects tackled, that same person helps another one on one of his tasks.
2. Have two tasks where everyone helps tackling them.

Might not be a very exciting proposition but it would help eradicate
some serious difficulties we are experiencing.

> What is in your opinion priority for Emacs?

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, abrochard@gmx.com, rms@gnu.org,
>  emacs-devel@gnu.org
> Date: Tue, 22 Dec 2020 00:55:00 +0100
> 
> > > I don't see how anything different from the above could ever work, as
> > > long as the project continues to be a loosely coupled group of people
> > > with very disparate interests.  (I also see nothing wrong in how we do
> > > things, FWIW.)
> 
> There lies the problem.  The project cannot continue to be loosely coupled
> with very disparate interests.

OK, then let's close the project and all go home.

Re: Emacs Survey: Toolbars

[Stefan Monnier]

> OK, then let's close the project and all go home.

Hmm... I'm home already, I don't have anywhere else to go.


        Stefan

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 22, 2020 at 8:56 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: bugs@gnu.support, abrochard@gmx.com, rms@gnu.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, abrochard@gmx.com, rms@gnu.org,
> >  emacs-devel@gnu.org
> > Date: Tue, 22 Dec 2020 00:55:00 +0100
> >
> > > > I don't see how anything different from the above could ever work, as
> > > > long as the project continues to be a loosely coupled group of people
> > > > with very disparate interests.  (I also see nothing wrong in how we do
> > > > things, FWIW.)
> >
> > There lies the problem.  The project cannot continue to be loosely coupled
> > with very disparate interests.
>
> OK, then let's close the project and all go home.

The argument was to conrtol it better so things will stay within your reach.

Re: Emacs Survey: Toolbars

[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 argument was to conrtol it better so things will stay within your reach.

I think it would be really great if we could reshape our development
community into something more like a team.  But that is easier said
than done.  The first prerequisite is that the people in question
want to become a team.

-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

It is something we really lack and a transition that would elevate us to a new level.
It is difficult because we would need to work in a more disciplined way.  It's all
about focusing on the process rather than the target.  Most times, the best results
are achieved by doing what's best for oneself and the group.  The idea of mixed-strategy
equilibria and its proof started by John Neumann in 1944.

> Sent: Thursday, December 24, 2020 at 11:17 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: eliz@gnu.org, abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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 argument was to conrtol it better so things will stay within your reach.
>
> I think it would be really great if we could reshape our development
> community into something more like a team.  But that is easier said
> than done.  The first prerequisite is that the people in question
> want to become a team.
>
> --
> 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: Emacs Survey: Toolbars

[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 lies the problem.  The project cannot continue to be loosely coupled
  > with very disparate interests.  The major people involved should come together
  > as a team.  This means that they should spend some of their time looking at
  > the other interests.

This change might might be good in some ways, if the maintainers want
to do it -- but I'm not going to try twisting anyone's arm to make it happen.

-- 
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: Emacs Survey: Toolbars

[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 could also motivate by offering small payments for solutions to
  > unresolved problems.

Yes, we could do that.  It could be a useful practice.
And we would need to make a plan: a list of projects
(not very many of them, I'd think) that are of a reasonable size
and amounts to offer.

Do you think people could be motivated by amounts under hundreds
of dollars?  I tend to doubt it.

  > Most people I know don't know what to do or what problems are out there.

Is this because we have not posted it in a clear enough way
or because we have not made people aware of what we do post?
-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 22, 2020 at 10:51 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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 could also motivate by offering small payments for solutions to
>   > unresolved problems.
> 
> Yes, we could do that.  It could be a useful practice.
> And we would need to make a plan: a list of projects
> (not very many of them, I'd think) that are of a reasonable size
> and amounts to offer.
> 
> Do you think people could be motivated by amounts under hundreds
> of dollars?  I tend to doubt it.

I was thinking to say, ‘Here’s a nice problem, we thought about it for a while, and we 
don’t see how to solve it.  Maybe it’s a $25 problem or possibly a $100 problem.

Or offer things like membership, discounts, entry to LibrePlanet, or have certain
conditions for eligibility for specific internships.

I do not know how willing maintainers would be on offering a few weeks
internships locally.  The project community could contribute a few dollars
to have something comparable to Google Summer of Code for specific tasks. 
 
To really move forward we got to focus on young people with plenty of
enthusiasm and eager to prove themselves.

Have had discussions with many people in the last few years, and figured
out how difficult it is to work with older people who are most often set
in their ways or routine. 
 
>   > Most people I know don't know what to do or what problems are out there.
> 
> Is this because we have not posted it in a clear enough way
> or because we have not made people aware of what we do post?

Mostly because many need guide and experience to really have their 
own ideas for implementation.  Short manuals describing
topical  overview  areas with plenty of complementary material
on areas that require profound  understanding.  

> -- 
> 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: Emacs Survey: Toolbars

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:
> Do you think people could be motivated by amounts under hundreds
> of dollars?  I tend to doubt it.

FYI, amounts in order of tens of dollars are not that less if you live
in less developed countries. For example, a pay in non-capital cities in
Ukraine can be in order of 10-20$/day.

Best,
Ihor

Re: Emacs Survey: Toolbars

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

  > FYI, amounts in order of tens of dollars are not that less if you live
  > in less developed countries. For example, a pay in non-capital cities in
  > Ukraine can be in order of 10-20$/day.

I have the feeling that a task important enough to be worth offering a
reward for are likely to take over 100 days.  So that still means 1000
or 2000 dollars.


-- 
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: Emacs Survey: Toolbars

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

> I have the feeling that a task important enough to be worth offering a
> reward for are likely to take over 100 days.  So that still means 1000
> or 2000 dollars.

Then, we can allow people to donate/vote for specific tasks and
important tasks should be able to get that much fund (I imagine).
2000USD is 200 people donating 10USD. I guess that really important
tasks are the tasks that are wanted by several hundreds of people at
least.

Best,
Ihor

Re: Emacs Survey: Toolbars

[Jean Louis]

* Ihor Radchenko <yantar92@gmail.com> [2020-12-24 10:01]:
> Richard Stallman <rms@gnu.org> writes:
> 
> > I have the feeling that a task important enough to be worth offering a
> > reward for are likely to take over 100 days.  So that still means 1000
> > or 2000 dollars.
> 
> Then, we can allow people to donate/vote for specific tasks and
> important tasks should be able to get that much fund (I imagine).
> 2000USD is 200 people donating 10USD. I guess that really important
> tasks are the tasks that are wanted by several hundreds of people at
> least.

Very good idea!

Re: Emacs Survey: Toolbars

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

  > Then, we can allow people to donate/vote for specific tasks and
  > important tasks should be able to get that much fund (I imagine).

That is very terse, and I am not sure what it means in concrete terms.

-- 
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: Emacs Survey: Toolbars

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > Then, we can allow people to donate/vote for specific tasks and
>   > important tasks should be able to get that much fund (I imagine).
>
> That is very terse, and I am not sure what it means in concrete terms.

What I meant is something similar to kickstarter/indiegogo crowdfunding
model. Instead of donating to generic Emacs development, the users may
be given an option to give donation for a specific task. The accumulated
donations will be used to reward the contributors who close the task.
(There might be issues about splitting the reward if several people
contribute to the same task, but I believe that it can be worked out by
setting appropriate policies).

I think the similar idea is used in https://bountify.co/, judging from
their front page.

Best,
Ihor

Re: Emacs Survey: Toolbars

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

  > Instead of donating to generic Emacs development, the users may
  > be given an option to give donation for a specific task. The accumulated
  > donations will be used to reward the contributors who close the task.

That is much harder than it seems.  But this list is not the place to
discuss 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: Emacs Survey: Toolbars

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-12-22 08:22]:
> [[[ 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 could also motivate by offering small payments for solutions to
>   > unresolved problems.
> 
> Yes, we could do that.  It could be a useful practice.
> And we would need to make a plan: a list of projects
> (not very many of them, I'd think) that are of a reasonable size
> and amounts to offer.
> 
> Do you think people could be motivated by amounts under hundreds
> of dollars?  I tend to doubt it.

I think yes. Not everybody is too busy and programmers live in various
economical zones that smaller amounts not affordable in US could be
quite affordable for one month of living in some other country.

For example a waitress in Uganda would get monthly US $55 for salary
which would be short as one would need to pay the room, and food at
least. Majority of people live for less than US $100 per month.

>   > Most people I know don't know what to do or what problems are out there.
> 
> Is this because we have not posted it in a clear enough way
> or because we have not made people aware of what we do post?

In my opinion both. It has been posted on GNU website what is needed
in terms of critical software where GNU need help, but website is huge
and when there is complex information it may not be quite clear. In
terms of Emacs I do not know if GNU posted it anywhere but in
etc/TODO.

It would be good to make a list of items where Emacs need some help
including if there are some paid initiatives.

The free OS DragonflyBSD offers "Code Bounties"
https://www.dragonflybsd.org/docs/developer/Code_Bounties/ where some
people may say which feature they would like to see in Emacs and some
people program for the feature, so they could say US $100 within 6
months for the feature X to be programmed. We could use that as
example and I have proposed it before few weeks. There is no guarantee
offered that feature would be included even if programmed, developers
decide it ultimately. 

We could then all "bid" on various features or program for bidders
while improving free software.

Jean

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> Date: Tue, 22 Dec 2020 09:31:46 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Christopher Dimech <dimech@gmx.com>, abrochard@gmx.com, emacs-devel@gnu.org
> 
> > Is this because we have not posted it in a clear enough way
> > or because we have not made people aware of what we do post?
> 
> In my opinion both. It has been posted on GNU website what is needed
> in terms of critical software where GNU need help, but website is huge
> and when there is complex information it may not be quite clear. In
> terms of Emacs I do not know if GNU posted it anywhere but in
> etc/TODO.

It is customary for GNU projects to have a TODO file, and Emacs
follows suit.

Re: Emacs Survey: Toolbars

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

  > In my opinion both. It has been posted on GNU website what is needed
  > in terms of critical software where GNU need help, but website is huge
  > and when there is complex information it may not be quite clear. In
  > terms of Emacs I do not know if GNU posted it anywhere but in
  > etc/TODO.

We could certainly post an Emcas task list page.

-- 
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: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 22 Dec 2020 00:21:50 -0500
> Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
> 
>   > Most people I know don't know what to do or what problems are out there.
> 
> Is this because we have not posted it in a clear enough way
> or because we have not made people aware of what we do post?

We display the list of features we'd like implemented in etc/TODO.

Internationalize Emacs's messages (swahili)

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-22 18:41]:
> > From: Richard Stallman <rms@gnu.org>
> > Date: Tue, 22 Dec 2020 00:21:50 -0500
> > Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
> > 
> >   > Most people I know don't know what to do or what problems are out there.
> > 
> > Is this because we have not posted it in a clear enough way
> > or because we have not made people aware of what we do post?
> 
> We display the list of features we'd like implemented in etc/TODO.

Could I then arrange translations to Swahili (Kenya, Tanzania, Uganda,
Congo) and Luganda (Uganda) for Emacs?

Is it possible to start, like using gettext stuff?

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> Date: Tue, 22 Dec 2020 19:28:42 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, dimech@gmx.com, abrochard@gmx.com, bugs@gnu.support,
>   emacs-devel@gnu.org
> 
> Could I then arrange translations to Swahili (Kenya, Tanzania, Uganda,
> Congo) and Luganda (Uganda) for Emacs?
> 
> Is it possible to start, like using gettext stuff?

See the ngettext function.

Re: Internationalize Emacs's messages (swahili)

[Zhu Zihao]

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


Eli Zaretskii writes:

>> Date: Tue, 22 Dec 2020 19:28:42 +0300
>> From: Jean Louis <bugs@gnu.support>
>> Cc: rms@gnu.org, dimech@gmx.com, abrochard@gmx.com, bugs@gnu.support,
>>   emacs-devel@gnu.org
>> 
>> Could I then arrange translations to Swahili (Kenya, Tanzania, Uganda,
>> Congo) and Luganda (Uganda) for Emacs?
>> 
>> Is it possible to start, like using gettext stuff?
>
> See the ngettext function.

I see the the C code of ngettext.

  /* Placeholder implementation until we get our act together.  */
  return EQ (n, make_fixnum (1)) ? msgid : msgid_plural;

Looks that we're not ready for the i18n/l10n?


-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Zhu Zihao <all_but_last@163.com>
> Date: Wed, 23 Dec 2020 22:04:50 +0800
> Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org, bugs@gnu.support,
>  emacs-devel@gnu.org
> 
> >> Is it possible to start, like using gettext stuff?
> >
> > See the ngettext function.
> 
> I see the the C code of ngettext.
> 
>   /* Placeholder implementation until we get our act together.  */
>   return EQ (n, make_fixnum (1)) ? msgid : msgid_plural;
> 
> Looks that we're not ready for the i18n/l10n?

"Ready" in what sense?

There were serious discussions of this stuff in the past, which
revealed the parts of this (large) job, and in particular that just
having a Lisp binding for gettext is not enough.  We are "ready" in
the sense that someone needs to implement at least some of those
parts.

(This is about l10n; i18n is in Emacs since v20.1.)

Re: Internationalize Emacs's messages (swahili)

[Zhu Zihao]

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


Eli Zaretskii writes:

> There were serious discussions of this stuff in the past, which
> revealed the parts of this (large) job, and in particular that just
> having a Lisp binding for gettext is not enough.  We are "ready" in
> the sense that someone needs to implement at least some of those
> parts.

Can you give me a link to the dicussion?

So far as I can imagine, these problems should be solved before we
introduce l10n to Emacs.

1. Emacs should be able to compile gettext *.po file, not just read *.mo
file. It's not elegant to distribute package with *.mo files bundled.

2. More tightly integration to gettext tools. This may already be
solved, we can merge the po-mode.el from gettext project to Emacs and
improve it.

3. Namespace. In order to make all 3rd-party Emacs plugins to use
gettext l10n, we should provide a proper way to let plugins declare
their own text domain. And we may also need to resolve the conflict.
Since all plugins run with Emacs in same process. text domain name
confliction will be a big problem.

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Zhu Zihao <all_but_last@163.com>
> Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org, bugs@gnu.support,
>  emacs-devel@gnu.org
> Date: Thu, 24 Dec 2020 09:54:04 +0800
> 
> > There were serious discussions of this stuff in the past, which
> > revealed the parts of this (large) job, and in particular that just
> > having a Lisp binding for gettext is not enough.  We are "ready" in
> > the sense that someone needs to implement at least some of those
> > parts.
> 
> Can you give me a link to the dicussion?

They are easy enough to find: search the list archives for "gettext"
or "l10n", and you will find them.  The last one starts here:

  https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00081.html

A previous one starts here:

  https://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00750.html

> 1. Emacs should be able to compile gettext *.po file, not just read *.mo
> file. It's not elegant to distribute package with *.mo files bundled.
> 
> 2. More tightly integration to gettext tools. This may already be
> solved, we can merge the po-mode.el from gettext project to Emacs and
> improve it.
> 
> 3. Namespace. In order to make all 3rd-party Emacs plugins to use
> gettext l10n, we should provide a proper way to let plugins declare
> their own text domain. And we may also need to resolve the conflict.
> Since all plugins run with Emacs in same process. text domain name
> confliction will be a big problem.

These are technical problems that can be solved relatively easily.
The real issues are much harder, as discussed in those threads.

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Zhu Zihao <all_but_last@163.com>
>> Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org, bugs@gnu.support,
>>  emacs-devel@gnu.org
>> Date: Thu, 24 Dec 2020 09:54:04 +0800
>> 
>> > There were serious discussions of this stuff in the past, which
>> > revealed the parts of this (large) job, and in particular that just
>> > having a Lisp binding for gettext is not enough.  We are "ready" in
>> > the sense that someone needs to implement at least some of those
>> > parts.
>> 
>> Can you give me a link to the dicussion?
>
> They are easy enough to find: search the list archives for "gettext"
> or "l10n", and you will find them.  The last one starts here:
>
>   https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00081.html
>
> A previous one starts here:
>
>   https://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00750.html

My personal opinion is that gettext is too limited. It works for simple
things, but provides no help at all for complex things.

I think that the most productive way to think about translation is that
each coherent message that we present to a user (whether it's via the
message function or not) should explicitly be the result of calling a
function written by the translator. gettext only allows the translator
to supply strings, so it falls down in complex situations.

The classical example is the "You have 42 new messages." situation. With
gettext, it is tempting to ask the translator to translate a string such
as "You have %d new messages.", but this does not give them any
flexibility to correctly handle languages with more plural categories
than English. Russian, for example, has a plural category for all
numbers that are one more than a multiple of ten except 11, which is a
special case. It also has another category for all numbers ending in 2,
3, or 4 except for 12, 13, and 14. (I don't actually know Russian, but
the rules are summarized in a page or two at
<http://www.russianlessons.net/lessons/lesson11_main.php>.) There are
over 7,700 distinct languages in the world, and we should assume that
they are all at least that crazy. An ideal situation does not allow the
craziness to leave the translation and make the implementation more
complex. Nor should the craziness of Russian make writing a Spanish
translation more difficult.

Thus, each translation should provide a package full of functions rather
than a file full of strings. It could literally be that simple, though I
think that there are benefits to not making translators actually write
an elisp package. For one thing, putting the wrong kind of function in a
translation package could actually break Emacs (because there's no
namespacing). I think that we could compile these functions from a
different source representation, and that we could benefit from sharing
code and tools with an existing translation project.

I recommend taking a look at Project Fluent
<https://www.projectfluent.org/>. It's a free-software implementation of
exactly the system that I've described. Translators write functions in a
syntax that is similar in some ways to both Javascript and an ini file,
which could be easily compiled into Elisp. (It's the successor to the
l20n project, which you might also have heard of.)

The Project Fluent webpage has an set of interactive examples which are
worth checking out.

I'd be willing to spend some free time to help implement this.

db48x

Re: Internationalize Emacs's messages (swahili)

[Stefan Monnier]

> My personal opinion is that gettext is too limited. It works for simple
> things, but provides no help at all for complex things.

My feeling is that Emacs is so far from those problems that considering
such issues will do little more than delay any actual progress.


        Stefan   

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

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

>> My personal opinion is that gettext is too limited. It works for simple
>> things, but provides no help at all for complex things.
>
> My feeling is that Emacs is so far from those problems that considering
> such issues will do little more than delay any actual progress.

Possibly, but I'm not so sure. Just looking at the message function for
a moment (because it's easy to grep for), there are a nonzero number
that do numeric substitions. Here are a few selected examples:

    ./lisp/sort.el:638:      (message "Deleted %d %sduplicate line%s%s"
    ./lisp/calendar/cal-hebrew.el:188:  (message "Hebrew date (until sunset): %s"
    ./lisp/ido.el:1670:    (message "Ido mode %s" (if ido-mode "enabled" "disabled"))))
    ./lisp/calendar/appt.el:716:          (message "Appointment reminders enabled%s"
    ./lisp/calendar/icalendar.el:2287:                 (message "Cannot handle COUNT attribute for `%s' events."
    ./lisp/calendar/calendar.el:2040:    (message "Region has %d day%s (inclusive)"
    ./lisp/calendar/todo-mode.el:725:		       (message "There is no %s file for %s"
    ./lisp/calendar/todo-mode.el:5672:    (when prompt (message "Press a key (so far `%s'): %s" keys-so-far prompt))
    ./lisp/calendar/todo-mode.el:5772:	(message (concat "File" (if pl "s" "") " %s ha" (if pl "ve" "s")
    ./lisp/registry.el:317:	     (message "reindexing: %d of %d (%.2f%%)"

The one from todo-mode.el:5772 is quite interesting; you can see that
it's complex because it's handling English plurals. That complexity
would be moved into the English translation and out of todo-mode.el
entirely. The ones with colons are a way to make the substitution more
generic across languages by making plurals less necessary at the cost of
being more stilted.

db48x

Re: Internationalize Emacs's messages (swahili)

[Stefan Monnier]

>>> My personal opinion is that gettext is too limited. It works for simple
>>> things, but provides no help at all for complex things.
>> My feeling is that Emacs is so far from those problems that considering
>> such issues will do little more than delay any actual progress.
> Possibly, but I'm not so sure. Just looking at the message function for
> a moment (because it's easy to grep for), there are a nonzero number
> that do numeric substitions. Here are a few selected examples:

You're missing my point: last I checked, we have 0 translations (well,
beside the tutorials, that is).  So, worrying about addressing the
plurality of plurals better than most other programs doesn't seem right.


        Stefan

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

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

>>>> My personal opinion is that gettext is too limited. It works for simple
>>>> things, but provides no help at all for complex things.
>>> My feeling is that Emacs is so far from those problems that considering
>>> such issues will do little more than delay any actual progress.
>> Possibly, but I'm not so sure. Just looking at the message function for
>> a moment (because it's easy to grep for), there are a nonzero number
>> that do numeric substitions. Here are a few selected examples:
>
> You're missing my point: last I checked, we have 0 translations (well,
> beside the tutorials, that is).  So, worrying about addressing the
> plurality of plurals better than most other programs doesn't seem right.

Ah, ok. I suppose that's true. However, imagine the scenario in five
years when we have to rip out gettext and 42 translations and replace
them with something else because everyone is getting annoyed at how hard
it is to pluralize things correctly.

I don't think it will be all that difficult to do correctly, and if it
costs us a few months up front then in the long run that will be time
well-spent.

db48x

Re: Internationalize Emacs's messages (swahili)

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

  > Ah, ok. I suppose that's true. However, imagine the scenario in five
  > years when we have to rip out gettext and 42 translations and replace
  > them with something else because everyone is getting annoyed at how hard
  > it is to pluralize things correctly.

It is a mistake to make such specific assumptions about what we
will do, years from now.  We could do other things, such as.

* Not bother about it, because only a minority of users experience
a problem and it is merely the same annoyance they see in other programs.

* Fix it in gettext, for all GNU programs at once.


-- 
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: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Daniel Brooks <db48x@db48x.net> writes:

> Thus, each translation should provide a package full of functions rather
> than a file full of strings. It could literally be that simple, though I

As a concrete example of what I see in my head when I talk about this,
here's some code that generates a moderately complex message, which I
have taken from todo-mode.el:

    (let ((pl (> (length deleted) 1))
          (names (mapconcat (lambda (f) (concat "\"" f "\"")) deleted ", ")))
      (message (concat "File" (if pl "s" "") " %s ha" (if pl "ve" "s")
                       " been deleted and removed from\n"
                       "the list of category completion files")
               names))

I think that the best way to factor this code is this:

    (message (todo-msg-delete-from-category-completion-files deleted))

Basically, todo-msg-delete-from-category-completion-files is a new
function which bundles up all the work of creating the message to be
displayed. We pass it the list of deleted files, and it inspects the
user's preferences and does all the rest of the work. The naming scheme
is just what I came up with on the fly; it seems to me that it would
work, but it's a detail we should work out.

An obvious implementation of this function is this:

    (defun todo-msg-delete-from-category-completion-files (names)
        (let ((name (intern (concat "todo-msg-delete-from-category-completion-files-"
                                    (current-language-preference)))))
          (if (fboundp name)
              (funcall name names)
            (todo-msg-delete-from-category-completion-files-eng names))))

It just dispatches based on the user's currently-chosen language. The
function it dispatches to does the work of building or choosing a string
to return.  In those cases where we write code that should show a
message that is _not_ in the user's preferred language, we would call
the correct function ourselves. A good example of that would be the UI
that allows the user to choose a preferred language.

This could be included in todo-mode.el directly, but since todo-mode has
many messages to display, we would obviously want some macro for
declaring them in bulk. (That's another detail to be worked out.)

    (defun todo-msg-delete-from-category-completion-files-eng (names)
        (let ((category (plural-category-eng (length names)))
              (names (quoted-comma-sep names)))
          (format
           (cond ((eq :one category)
                  "File %s has been deleted and removed from\n the list of category completion files")
                 ((eq :other category)
                  "Files %s have been deleted and removed from\n the list of category completion files"))
           names)))

This is the one that does the real work. It chooses which string to use
based on the plural category (there are obviously briefer ways to write
this, but I wrote it this way for effect). It substitutes in the list of
files the normal way because english doesn't make us do anything odd for
that. (It would be nice if the formatted list had an "and" before the
final item though.)

This code could be written by hand with no trouble, and a translator who
knows Elisp could come in and supply a new group of functions that
implement the same interface but for their own language.

If we did the additional work of writing a Fluent→Elisp compiler, we
could write the same function something like this:

    delete-from-category-completion-files = { $names ->
        [one] File { quoted-comma-sep($names) } has been deleted and removed from\n the list of category completion files
       *[other] Files { quoted-comma-sep($names) } have been deleted and removed from\n the list of category completion files
    }

This is rather more succinct, and possible to teach to translators
without having to teach them all of elisp. We can compile this to Elisp
at build time, but I'd like to be able to load them dynamically as well.

The helper functions are all fairly obvious, and obviously incomplete:

    (defun plural-category-eng (count)
      (cond ((= count 1) :one)
            (t :other)))

    (defun current-language-preference ()
      "eng")

    (defun quoted-comma-sep (list)
      (mapconcat (lambda (f) (concat "\"" f "\"")) list ", "))

The current language preference could be a cusomizable variable, or some
other mechanism (a fallback to the LANG variable, for instance).

Each translation would have something like the quoted-comma-sep
function, though they might not all call it the same thing. This would
allow each translator to choose the most appropriate type of quotation
characters, list separators, conjunctions, and so on for the translation
that they are writing.

I think that all of this is doable in a reasonable amount of time, if
two or three people are working on it together. The broader work of
actually factoring messages out of the code and into translatable
functions would need to be spread out more broadly, but it could happen
over a longer period of time. It's a task of Herculean proportions, and
there is no conveniently-located river that we can divert.

It occurs to me that I haven't considered messages generated by C code
at all; I hope that they are few and far between, and that we can just
call back into lisp to generate those messages. There are bound to be
some messages that we just never end up translating.

db48x

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Daniel Brooks <db48x@db48x.net>
> Cc: Zhu Zihao <all_but_last@163.com>,  bugs@gnu.support,  dimech@gmx.com,
>   abrochard@gmx.com,  emacs-devel@gnu.org,  rms@gnu.org
> Date: Fri, 25 Dec 2020 22:06:15 -0800
> 
> As a concrete example of what I see in my head when I talk about this,
> here's some code that generates a moderately complex message, which I
> have taken from todo-mode.el:
> 
>     (let ((pl (> (length deleted) 1))
>           (names (mapconcat (lambda (f) (concat "\"" f "\"")) deleted ", ")))
>       (message (concat "File" (if pl "s" "") " %s ha" (if pl "ve" "s")
>                        " been deleted and removed from\n"
>                        "the list of category completion files")
>                names))

Thanks for pointing this out.  I've now fixed this and other similar
places in todo-mode.el on the master branch by using 'ngettext'.  The
diffs are below.

commit cf1d7034445e7896c34f88256e5d7f2674a4f7ee
Author:     Eli Zaretskii <eliz@gnu.org>
AuthorDate: Sat Dec 26 10:23:04 2020 +0200
Commit:     Eli Zaretskii <eliz@gnu.org>
CommitDate: Sat Dec 26 10:23:04 2020 +0200

    Fix messages with plural forms in todo-mode.el
    
    * lisp/calendar/todo-mode.el (todo-move-item, todo-item-undone)
    (todo-category-completions): Use 'ngettext' instead of hard-coding
    plural forms by hand.

diff --git a/lisp/calendar/todo-mode.el b/lisp/calendar/todo-mode.el
index 3975a9b..637df85 100644
--- a/lisp/calendar/todo-mode.el
+++ b/lisp/calendar/todo-mode.el
@@ -2745,9 +2745,10 @@ todo-move-item
 		(setq ov (make-overlay (save-excursion (todo-item-start))
 				       (save-excursion (todo-item-end))))
 		(overlay-put ov 'face 'todo-search))
-	      (let* ((pl (if (and marked (> (cdr marked) 1)) "s" ""))
-		     (cat+file (todo-read-category (concat "Move item" pl
-							    " to category: ")
+	      (let* ((num (if (not marked) 1 (cdr marked)))
+		     (cat+file (todo-read-category
+                                (ngettext "Move item to category: "
+                                          "Move items to category: " num)
 						    nil file)))
 		(while (and (equal (car cat+file) cat1)
 			    (equal (cdr cat+file) file1))
@@ -2974,7 +2975,7 @@ todo-item-undone
   (interactive)
   (let* ((cat (todo-current-category))
 	 (marked (assoc cat todo-categories-with-marks))
-	 (pl (if (and marked (> (cdr marked) 1)) "s" "")))
+	 (num (if (not marked) 1 (cdr marked))))
     (when (or marked (todo-done-item-p))
       (let ((buffer-read-only)
 	    (opoint (point))
@@ -2982,6 +2983,9 @@ todo-item-undone
 	    (first 'first)
 	    (item-count 0)
 	    (diary-count 0)
+            (omit-prompt (ngettext "Omit comment from restored item? "
+                                   "Omit comments from restored items? "
+                           num))
 	    start end item ov npoint undone)
 	(and marked (goto-char (point-min)))
 	(catch 'done
@@ -3013,10 +3017,7 @@ todo-item-undone
 		      (if (eq first 'first)
 			  (setq first
 				(if (eq todo-undo-item-omit-comment 'ask)
-				    (when (todo-y-or-n-p
-					   (concat "Omit comment" pl
-						   " from restored item"
-						   pl "? "))
+				    (when (todo-y-or-n-p omit-prompt)
 				      'omit)
 				  (when todo-undo-item-omit-comment 'omit)))
 			t)
@@ -5782,11 +5783,13 @@ todo-category-completions
 	      (delete f todo-category-completions-files))
 	(push f deleted)))
     (when deleted
-      (let ((pl (> (length deleted) 1))
+      (let ((ndeleted (length deleted))
 	    (names (mapconcat (lambda (f) (concat "\"" f "\"")) deleted ", ")))
-	(message (concat "File" (if pl "s" "") " %s ha" (if pl "ve" "s")
-			 " been deleted and removed from\n"
-			 "the list of category completion files")
+	(message (concat
+                  (ngettext "File %s has been deleted and removed from\n"
+                            "Files %s have been deleted and removed from\n"
+                            ndeleted)
+		  "the list of category completion files")
 		 names))
       (put 'todo-category-completions-files 'custom-type
            `(set ,@(todo--files-type-list)))

Re: Internationalize Emacs's messages (swahili)

[tomas]

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

On Fri, Dec 25, 2020 at 10:06:15PM -0800, Daniel Brooks wrote:
> Daniel Brooks <db48x@db48x.net> writes:
> 
> > Thus, each translation should provide a package full of functions rather
> > than a file full of strings. It could literally be that simple, though I
> 
> As a concrete example of what I see in my head when I talk about this,
> here's some code that generates a moderately complex message, which I
> have taken from todo-mode.el:

Before you set out to reinvent wheels, you should check what's out
there. The ngettext interface [1], which _is_ part of the gettext
package, addresses (even multiple!) plural forms, i.e. your Slavic
example.

Thing is, human languages are messy. You won't get everything covered.
And the more elaborate you get, the more difficult it'll be to find
translators having the time to grok all that complexity.

One of the nice things about this simplistic string -> string approach
is that it allows "lightweight" distributed translation approaches,
often web-based: those allow people to contribute translations to a
project who otherwise wouldn't even dream of contributing.

There are even platforms out there where you can register your Free
Software project and where people can contribute translations, via
a Web interface.

As always, it's a tradeoff.

Cheers

[1] https://en.wikipedia.org/wiki/Gettext#Plural_form

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Fri 25 Dec 2020 at 22:06, Daniel Brooks <db48x@db48x.net> wrote:
>     (let ((pl (> (length deleted) 1))

On a different note, there are 725 matches for "> (length" in Emacs.
Computing length first and then comparing the number of items is very
inefficient.  There is a room for speed up here.  I wonder if there is a
way to prevent programers to do such inefficient things?

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: rms@gnu.org, bugs@gnu.support, dimech@gmx.com,
> 	abrochard@gmx.com, emacs-devel@gnu.org,
> 	Zhu Zihao <all_but_last@163.com>
> Date: Sat, 26 Dec 2020 10:06:03 +0100
> 
> On Fri 25 Dec 2020 at 22:06, Daniel Brooks <db48x@db48x.net> wrote:
> >     (let ((pl (> (length deleted) 1))
> 
> On a different note, there are 725 matches for "> (length" in Emacs.
> Computing length first and then comparing the number of items is very
> inefficient.

What did you have in mind that would be more efficient?

The above code sets 'pl' to a simple boolean based on whether
'deleted' has one member or more than one.  What more efficient code
would you suggest here?

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tomas Hlavaty <tom@logand.com>
>> Cc: rms@gnu.org, bugs@gnu.support, dimech@gmx.com,
>> 	abrochard@gmx.com, emacs-devel@gnu.org,
>> 	Zhu Zihao <all_but_last@163.com>
>> Date: Sat, 26 Dec 2020 10:06:03 +0100
>> 
>> On Fri 25 Dec 2020 at 22:06, Daniel Brooks <db48x@db48x.net> wrote:
>> >     (let ((pl (> (length deleted) 1))
>> 
>> On a different note, there are 725 matches for "> (length" in Emacs.
>> Computing length first and then comparing the number of items is very
>> inefficient.
>
> What did you have in mind that would be more efficient?
>
> The above code sets 'pl' to a simple boolean based on whether
> 'deleted' has one member or more than one.  What more efficient code
> would you suggest here?

(not (null (cdr deleted))) would avoid traversing the entire list, but it
wouldn't be easier to read.

db48x

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Daniel Brooks <db48x@db48x.net> writes:

>> The above code sets 'pl' to a simple boolean based on whether
>> 'deleted' has one member or more than one.  What more efficient code
>> would you suggest here?
>
> (not (null (cdr deleted))) would avoid traversing the entire list, but it
> wouldn't be easier to read.

Perhaps a `longer-than-p' function would be helpful?  I.e.,
(longer-than-p deleted 1)?  (Or some better name.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Daniel Brooks <db48x@db48x.net> writes:
>
>>> The above code sets 'pl' to a simple boolean based on whether
>>> 'deleted' has one member or more than one.  What more efficient code
>>> would you suggest here?
>>
>> (not (null (cdr deleted))) would avoid traversing the entire list, but it
>> wouldn't be easier to read.
>
> Perhaps a `longer-than-p' function would be helpful?  I.e.,
> (longer-than-p deleted 1)?  (Or some better name.)

Yes, that would be a good readable name for it.

db48x

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 26 Dec 2020 10:34:46 +0100
> 
> > (not (null (cdr deleted))) would avoid traversing the entire list, but it
> > wouldn't be easier to read.
> 
> Perhaps a `longer-than-p' function would be helpful?  I.e.,
> (longer-than-p deleted 1)?  (Or some better name.)

Just add an optional arg LIMIT to 'length', since the implementation
will be the same, and you just want to terminate the loop as early as
possible.

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Sat, 26 Dec 2020 10:34:46 +0100
>> 
>> > (not (null (cdr deleted))) would avoid traversing the entire list, but it
>> > wouldn't be easier to read.
>> 
>> Perhaps a `longer-than-p' function would be helpful?  I.e.,
>> (longer-than-p deleted 1)?  (Or some better name.)
>
> Just add an optional arg LIMIT to 'length', since the implementation
> will be the same, and you just want to terminate the loop as early as
> possible.

I would still define functions with specific names like longer-than-p
which have names that specify their exact meaning, even if they just
call length with extra arguments.

db48x

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sat 26 Dec 2020 at 11:54, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Sat, 26 Dec 2020 10:34:46 +0100
>> 
>> > (not (null (cdr deleted))) would avoid traversing the entire list, but it
>> > wouldn't be easier to read.
>> 
>> Perhaps a `longer-than-p' function would be helpful?  I.e.,
>> (longer-than-p deleted 1)?  (Or some better name.)
>
> Just add an optional arg LIMIT to 'length', since the implementation
> will be the same, and you just want to terminate the loop as early as
> possible.

What about length= length/= length< length<= length> length>=
predicates?

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Tomas Hlavaty <tom@logand.com> writes:

> On Sat 26 Dec 2020 at 11:54, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Lars Ingebrigtsen <larsi@gnus.org>
>>> Date: Sat, 26 Dec 2020 10:34:46 +0100
>>> 
>>> > (not (null (cdr deleted))) would avoid traversing the entire list, but it
>>> > wouldn't be easier to read.
>>> 
>>> Perhaps a `longer-than-p' function would be helpful?  I.e.,
>>> (longer-than-p deleted 1)?  (Or some better name.)
>>
>> Just add an optional arg LIMIT to 'length', since the implementation
>> will be the same, and you just want to terminate the loop as early as
>> possible.
>
> What about length= length/= length< length<= length> length>=
> predicates?

Reasonable suggestions, but not in my opinion as readable as
`longer-than-p', `shorter-than-p', and so on.

db48x

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 26 Dec 2020 12:12:46 +0100
> 
> >> Perhaps a `longer-than-p' function would be helpful?  I.e.,
> >> (longer-than-p deleted 1)?  (Or some better name.)
> >
> > Just add an optional arg LIMIT to 'length', since the implementation
> > will be the same, and you just want to terminate the loop as early as
> > possible.
> 
> What about length= length/= length< length<= length> length>=
> predicates?

the first two don't need anything new, the rest can be handled with
the single argument I proposed and a negation function (which we
already have).  Right?

Re: Internationalize Emacs's messages (swahili)

[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 about length= length/= length< length<= length> length>=
  > predicates?

One of the basic design guides of Emacs Lisp is rejection of
the idea of adding more functions in the name of symmetry.

If there is a use for longer-than-p, or length> we could call it,
it may be worth adding that function, but let's skip the other 5
if they are not actually needed.

-- 
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: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 00:38, Richard Stallman <rms@gnu.org> wrote:
>   > What about length= length/= length< length<= length> length>=
>   > predicates?
>
> One of the basic design guides of Emacs Lisp is rejection of
> the idea of adding more functions in the name of symmetry.

Interesting.  Where can I read about the "basic design guides of Emacs
Lisp"?

I looked at "(elisp) Programming Tips" but did not find anything.  rgrep
on the emacs repository shows some counter-examples, i.e. stuff added in
the name of symmetry.

It is not clear, what exactly "the idea of adding more functions in the
name of symmetry" means.  Elisp has = /= < > <= >= predicates.  Does it
mean that <= /= > >= are against that idea because they can be trivially
expressed using = and < so programmers should write those "expansions"
by hand all over the place?

rgrep gives me the following hits:

216 "(not (="
 19 "(not (>"
 12 "(not (<"
  3 "(not (<="
  1 "(not (>="
  0 "(not (/="

Each usage of not makes the code harder to reason about.

I personally prefer the following heuristic:

- use < and <= rather than > and >= (read the predicate left to right
  from smaller to bigger values)

- prefer when/unless/while/until and swap if branches to using /= or
  negation

This way there is almost no need for /= > >=, except they are still
needed for convenience when used in a different context, e.g. when
passed as an arg to a function.

> If there is a use for longer-than-p, or length> we could call it,
> it may be worth adding that function, but let's skip the other 5
> if they are not actually needed.

rgrep on the emacs repository gives me the following counts:

732 "(> (length"
703 "(= (length"
151 "(< (length"
 71 "(>= (length"
 66 "(<= (length"
 46 "(/= (length"

Using length in a predicate smells fischy.  It is most likely a source
of unnecessarily burned cpu cycles.  It might be futile to train
programmers to keep that in mind but it is relatively easy to find and
fix.

There are (+ 732 703 151 71 66 46) => 1769 potential cases in emacs.
That's quite a lot of potential low hanging fruit for improvement.

Defining all those predicates will allow to syntactically fix those
places without touching anything else.  Once those predicates are in
place, we can be _sure_ that emacs is not uselessly counting length of
lists in predicates.  And those predicates could be further improved and
optimized in the future without affecting the call sites.

Now the questions is, how should such predicates look like.  Ideally,
they would look like = /= < > <= >= (accepting rest args) and numbers or
lists where for lists lengths would be computed but short-circuited.
But such generality might be overkill so I do not have an oppinion on
that.

Another issue already raised was: in C or elisp?  If compiler-macros
were an option, maybe that would give the most flexible and efficient
implementation which would be easy to maintain.  But I do not know much
about such deep elisp details yet.

Re: Internationalize Emacs's messages (swahili)

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

  > Interesting.  Where can I read about the "basic design guides of Emacs
  > Lisp"?

I have never tried to write them down in one specific place.

  > It is not clear, what exactly "the idea of adding more functions in the
  > name of symmetry" means.  Elisp has = /= < > <= >= predicates.  Does it
  > mean that <= /= > >= are against that idea because they can be trivially
  > expressed using = and < so programmers should write those "expansions"
  > by hand all over the place?

The idea here is only that we should not _automatically and rigidly_
complete every symmetric set of possible functions.  (Because that way
lies more bloat.)

I describ this as a "design guide" because that is different from a
rule.

If we had a rigid rule against full symmetric sets of functions, these
comparison functions would break the rule.  To be rigid about it, we
would be "obligated" to delete some of them.

However, the idea of the design guide is to reject the rigid rule,
which some systems seem to follow, that every function _must_ be part
of a full symmetric set.

-- 
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: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Perhaps a `longer-than-p' function would be helpful?  I.e.,
>> (longer-than-p deleted 1)?  (Or some better name.)
>
> Just add an optional arg LIMIT to 'length', since the implementation
> will be the same, and you just want to terminate the loop as early as
> possible.

Sure, as a practical matter, adding an optional LIMIT to length is
probably the way to implement this.  But I think adding some predicates
(like the length< etc predicated proposed by Tomas) as wrappers around
calls to length with LIMIT makes sense for code readability.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Sure, as a practical matter, adding an optional LIMIT to length is
> probably the way to implement this.  But I think adding some predicates
> (like the length< etc predicated proposed by Tomas) as wrappers around
> calls to length with LIMIT makes sense for code readability.

Actually...  looking a Flength, perhaps not adding an optional parameter
would be better.  I mean, the only type that's not constant in time is
the length of lists, so I think perhaps it would just be confusing.

Adding length=, length< and length> (as C functions) seems pretty
trivial -- punt to Flength for anything that's not a list, and handle
lists specially.  Those would have clear semantics, be fast, not make
Flength calls any slower, and not add more complicated semantics to
Flength.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Stefan Monnier]

> Actually...  looking a Flength, perhaps not adding an optional parameter
> would be better.  I mean, the only type that's not constant in time is
> the length of lists, so I think perhaps it would just be confusing.
>
> Adding length=, length< and length> (as C functions) seems pretty
> trivial -- punt to Flength for anything that's not a list, and handle
> lists specially.  Those would have clear semantics, be fast, not make
> Flength calls any slower, and not add more complicated semantics to
> Flength.

I agree that adding an arg to `length` is probably not a good idea.

But how serious is this need we're talking about?
I mean we can already easily implement those things in ELisp:

    (defun length> (x n)
      "Non-nil if length of X is greater than N."
      (if (consp x)
          (nthcdr n x)
        (> (length x) n)))


-- Stefan

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

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

> But how serious is this need we're talking about?
> I mean we can already easily implement those things in ELisp:

Oh, sure.  But since this is a pure speed optimisation we're talking
about, the Lisp solution would be slower than the (< (length foo) bar)
in a significant number of cases, and we don't want that, do we?

(Most lists in Emacs are very short.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Stefan Monnier]

>> But how serious is this need we're talking about?
>> I mean we can already easily implement those things in ELisp:
> Oh, sure.  But since this is a pure speed optimisation we're talking
> about, the Lisp solution would be slower than the (< (length foo) bar)
> in a significant number of cases, and we don't want that, do we?

Actually, AFAICT this all started from:

    (not (null (cdr deleted))) would avoid traversing the entire list,
    but it wouldn't be easier to read.

which doesn't actually demonstrate a need for "speed optimisation", but
rather a need to avoid extra work (which could lead to real performance
problems when the list is long), so the ELisp implementation seems to
fit the bill ("avoid traversing the entire list" while being "easier to
read").


        Stefan

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

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

> Actually, AFAICT this all started from:
>
>     (not (null (cdr deleted))) would avoid traversing the entire list,
>     but it wouldn't be easier to read.
>
> which doesn't actually demonstrate a need for "speed optimisation", but
> rather a need to avoid extra work (which could lead to real performance
> problems when the list is long), so the ELisp implementation seems to
> fit the bill ("avoid traversing the entire list" while being "easier to
> read").

Well, it started from (< (length list) ...), and the not-null-cdr was
mooted as a faster, but less readable solution.

A Lisp function would be slower (in many cases), but more readable.

I'm proposing a solution that's faster, and more readable.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

I whipped one up quickly.  The slightly interesting thing here is that
we have an opportunity here to make this slightly faster -- since we
have an upper length bound here, we can eschew the tortoise/hare
FOR_EACH_TAIL bit and just follow CDRs, which would be faster.  Of
course, if you give it a circular list, then it'll always return Qnil,
and if you give it (expt most-positive-fixnum most-positive-fixnum) on a
circular list, it'll take a while...

diff --git a/src/fns.c b/src/fns.c
index 646c3ed083..2234818e8e 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -145,6 +145,29 @@ DEFUN ("safe-length", Fsafe_length, Ssafe_length, 1, 1, 0,
   return make_fixnum (len);
 }
 
+DEFUN ("length<", Flength_less, Slength_less, 2, 2, 0,
+       doc: /* Return non-nil if SEQUENCE is shorter than LENGTH.
+See `length' for allowed values of SEQUENCE.  */)
+  (Lisp_Object sequence, Lisp_Object length)
+{
+  CHECK_INTEGER (length);
+  EMACS_INT len = XFIXNUM (length);
+
+  if (CONSP (sequence))
+    {
+      intptr_t i = 0;
+      FOR_EACH_TAIL (sequence)
+	{
+	  i++;
+	  if (i >= len)
+	    return Qnil;
+	}
+      return Qt;
+    }
+  else
+    return XFIXNUM (Flength (sequence)) < len? Qt: Qnil;
+}
+
 DEFUN ("proper-list-p", Fproper_list_p, Sproper_list_p, 1, 1, 0,
        doc: /* Return OBJECT's length if it is a proper list, nil otherwise.
 A proper list is neither circular nor dotted (i.e., its last cdr is nil).  */
@@ -5721,6 +5744,7 @@ syms_of_fns (void)
   defsubr (&Srandom);
   defsubr (&Slength);
   defsubr (&Ssafe_length);
+  defsubr (&Slength_less);
   defsubr (&Sproper_list_p);
   defsubr (&Sstring_bytes);
   defsubr (&Sstring_distance);

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I whipped one up quickly.

With this totally realistic benchmark, this is what we have today:

(let ((list (make-list 10000 nil)))
  (benchmark-run 1000000 (< (length list) 2)))
=> (10.826215101 0 0.0)

The same, with length<:

(let ((list (make-list 10000 nil)))
  (benchmark-run 1000000 (length< list 2)))
=> (0.05590014099999999 0 0.0)

If we avoid tortoise/hare for small LENGTHs, then it's about 20% faster
than that again (if we're doing (length< list 200)).

diff --git a/src/fns.c b/src/fns.c
index 646c3ed083..2557f41637 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -145,6 +145,37 @@ DEFUN ("safe-length", Fsafe_length, Ssafe_length, 1, 1, 0,
   return make_fixnum (len);
 }
 
+DEFUN ("length<", Flength_less, Slength_less, 2, 2, 0,
+       doc: /* Return non-nil if SEQUENCE is shorter than LENGTH.
+See `length' for allowed values of SEQUENCE.  */)
+  (Lisp_Object sequence, Lisp_Object length)
+{
+  CHECK_FIXNUM (length);
+  EMACS_INT len = XFIXNUM (length);
+
+  if (CONSP (sequence))
+    {
+      EMACS_INT i = 0;
+      /* If LENGTH is short, use a fast loop that doesn't care about
+	 whether SEQUENCE is circular or not. */
+      if (len < 0xffff)
+	while (CONSP (sequence))
+	  {
+	    if (++i >= len)
+	      return Qnil;
+	    sequence = XCDR (sequence);
+	  }
+      /* Signal an error on circular lists. */
+      else
+	FOR_EACH_TAIL (sequence)
+	  if (++i >= len)
+	    return Qnil;
+      return Qt;
+    }
+  else
+    return XFIXNUM (Flength (sequence)) < len? Qt: Qnil;
+}
+
 DEFUN ("proper-list-p", Fproper_list_p, Sproper_list_p, 1, 1, 0,
        doc: /* Return OBJECT's length if it is a proper list, nil otherwise.
 A proper list is neither circular nor dotted (i.e., its last cdr is nil).  */
@@ -5721,6 +5752,7 @@ syms_of_fns (void)
   defsubr (&Srandom);
   defsubr (&Slength);
   defsubr (&Ssafe_length);
+  defsubr (&Slength_less);
   defsubr (&Sproper_list_p);
   defsubr (&Sstring_bytes);
   defsubr (&Sstring_distance);


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> +DEFUN ("length<", Flength_less, Slength_less, 2, 2, 0,

I went ahead and pushed this (along with > and =, which seems like a
natural set).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 27 Dec 2020 09:01:48 +0100
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > +DEFUN ("length<", Flength_less, Slength_less, 2, 2, 0,
> 
> I went ahead and pushed this (along with > and =, which seems like a
> natural set).

Like Richard, I think that not all of the functions are needed,
because some can be trivially expressed by others.

I thought we always implemented only the minimum required set.  For
example, we have version<, but not version>=; we have
string-collate-lessp, but not string-collate-greaterp.  Why do we need
to stray from that principle in this case?  And if we must have all of
those functions, why cannot they share most of their code?

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I went ahead and pushed this (along with > and =, which seems like a
>> natural set).
>
> Like Richard, I think that not all of the functions are needed,
> because some can be trivially expressed by others.

Yes, I think <, = and > are the ones that are nice to have.  The /=, <=
and >= are trivial to express via the others, so I didn't go there.

> I thought we always implemented only the minimum required set.  For
> example, we have version<, but not version>=; we have
> string-collate-lessp, but not string-collate-greaterp.

I'm generally in favour of >, but these two are almost only used for
sorting, which makes the other forms superfluous.  (I know that there
are people who insist that < should be the only operator, and they write
code like (if (< 50 tom's-age) ...), and in my experience that leads to
people not being able to read the resulting code.)

> Why do we need to stray from that principle in this case?  And if we
> must have all of those functions, why cannot they share most of their
> code?

People say (if (< (length ...))) and (if (> (length... ))) (and =) all
over the place -- it's not used as a sorting predicate, so having the
these three seemed like the minimal set.

And I don't quite follow you -- they do share most of their code?  I
think you could push a few more lines into the shared function, but I
think the resulting code would be pretty obscure.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 23:03, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> Like Richard, I think that not all of the functions are needed,
>> because some can be trivially expressed by others.

> Yes, I think <, = and > are the ones that are nice to have.  The /=,
> <= and >= are trivial to express via the others, so I didn't go there.

>> Why do we need to stray from that principle in this case?  And if we
>> must have all of those functions

> People say (if (< (length ...))) and (if (> (length... ))) (and =) all
> over the place -- it's not used as a sorting predicate, so having the
> these three seemed like the minimal set.

It is unlikely that people stop counting all elements of lists.

However, if somebody writes such code, it is almost trivial to fix it
with search and replace:

   "(= (length" -> "(length="
   "(< (length" -> "(length<"
   "(> (length" -> "(length>"
   "(/= (length" -> "(length/="
   "(<= (length" -> "(length<="
   "(>= (length" -> "(length>="

(plus extra closing paren)

The "symmetry" (or exhaustiveness?) here is to assist with easily fixing
bad code with minimum changes, i.e. one does not need to think how to
express it using different code.

Example:

   (<= (length ...) ...)
   ->
   (not (length> ...))

Visually different.  (I hope I got it right:-)

versus:

   (<= (length ...) ...)
   ->
   (length<= ...)

Visually same.

So once in a while, it will be possible to search and replace those bad
cases without any mental overhead, just with visual review.

In any case, thanks for taking initiative and improving this!

Re: Internationalize Emacs's messages (swahili)

[Alfred M. Szmidt]

   However, if somebody writes such code, it is almost trivial to fix it
   with search and replace:

      "(= (length" -> "(length="
      "(< (length" -> "(length<"
      "(> (length" -> "(length>"
      "(/= (length" -> "(length/="
      "(<= (length" -> "(length<="
      "(>= (length" -> "(length>="

   (plus extra closing paren)

Users will assume that these length>= hacks will make their code
magically better, when they just hide a problematic form -- doing a
possibly complicated operation inside a predicate call.

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 17:49, "Alfred M. Szmidt" <ams@gnu.org> wrote:
>    However, if somebody writes such code, it is almost trivial to fix
>    it with search and replace:
>
>       "(= (length" -> "(length="
>       "(< (length" -> "(length<"
>       "(> (length" -> "(length>"
>       "(/= (length" -> "(length/="
>       "(<= (length" -> "(length<="
>       "(>= (length" -> "(length>="
>
>    (plus extra closing paren)
>
> Users will assume that these length>= hacks will make their code
> magically better, when they just hide a problematic form -- doing a
> possibly complicated operation inside a predicate call.

It will make their code better.  I do not see any magic there, it is
pretty simple and logical.

Do you have some other solution on mind?

lengths and other stuff

[Daniel Brooks]

Tomas Hlavaty <tom@logand.com> writes:

> On Sun 27 Dec 2020 at 17:49, "Alfred M. Szmidt" <ams@gnu.org> wrote:
>>    However, if somebody writes such code, it is almost trivial to fix
>>    it with search and replace:
>>
>>       "(= (length" -> "(length="
>>       "(< (length" -> "(length<"
>>       "(> (length" -> "(length>"
>>       "(/= (length" -> "(length/="
>>       "(<= (length" -> "(length<="
>>       "(>= (length" -> "(length>="
>>
>>    (plus extra closing paren)
>>
>> Users will assume that these length>= hacks will make their code
>> magically better, when they just hide a problematic form -- doing a
>> possibly complicated operation inside a predicate call.
>
> It will make their code better.  I do not see any magic there, it is
> pretty simple and logical.
>
> Do you have some other solution on mind?

Some of them can no doubt be replaced by multiple-value-bind and other
such things. This one from ido.el:1518, for example:

    (if (and (listp (car l))
             (> (length (car l)) 2)
             (let ((dir (car (car l)))
                   (time (car (cdr (car l))))
                   (files (cdr (cdr (car l)))))

could be (multiple-value-bind (dir time files) (car l) …).

But those kinds of improvements take a lot more thought about each
occurrence.

Incidentally, I find it hard to believe that someone typed all of that
out without at least using cadar and cddar.

db48x

Re: lengths and other stuff

[Lars Ingebrigtsen]

Daniel Brooks <db48x@db48x.net> writes:

> Incidentally, I find it hard to believe that someone typed all of that
> out without at least using cadar and cddar.

It's very old code...  didn't `cadar' and friends get added kinda late?
(I.e., 90s?)  I vaguely seem to remember them living in cl.el for a
while until people were convinced to hoist them to Emacs proper.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: lengths and other stuff

[Daniel Brooks]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Daniel Brooks <db48x@db48x.net> writes:
>
>> Incidentally, I find it hard to believe that someone typed all of that
>> out without at least using cadar and cddar.
>
> It's very old code...  didn't `cadar' and friends get added kinda late?
> (I.e., 90s?)  I vaguely seem to remember them living in cl.el for a
> while until people were convinced to hoist them to Emacs proper.

A quick check does show that they were moved to subr.el from cl-lib.el
just three years ago. Nearly four now. Also that they were called
cl-cadar and so on. Weird.

db48x

Re: lengths and other stuff

[Lars Ingebrigtsen]

Daniel Brooks <db48x@db48x.net> writes:

> A quick check does show that they were moved to subr.el from cl-lib.el
> just three years ago. Nearly four now. Also that they were called
> cl-cadar and so on. Weird.

Oh, right.  But before the cl->cl-lib makeover, we used to sprinkle all
(FSVO) files with

(eval-when-compile (require 'cl-macs))

and `cadar' and friends were ... macros?  Hm.  Well, I know I've used
`cadar' before 2017 somehow.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: lengths and other stuff

[Daniel Brooks]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> and `cadar' and friends were ... macros?  Hm.  Well, I know I've used
> `cadar' before 2017 somehow.  :-)

That does seem likely!

db48x

Re: lengths and other stuff

[Stefan Monnier]

> (eval-when-compile (require 'cl-macs))
> and `cadar' and friends were ... macros?

No, they were functions, but inlined at compile time (just as is the
case now).


        Stefan

Re: lengths and other stuff

[Stefan Monnier]

> A quick check does show that they were moved to subr.el from cl-lib.el
> just three years ago. Nearly four now. Also that they were called
> cl-cadar and so on. Weird.

That's because they suck.  They feel to me like programming in
assembler.  You're usually much better off using `nth` or `pcase` or
`cl-destructuring-bind`, ...


        Stefan

Re: lengths and other stuff

[Daniel Brooks]

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

>> A quick check does show that they were moved to subr.el from cl-lib.el
>> just three years ago. Nearly four now. Also that they were called
>> cl-cadar and so on. Weird.
>
> That's because they suck.  They feel to me like programming in
> assembler.  You're usually much better off using `nth` or `pcase` or
> `cl-destructuring-bind`, ...

Definitely. But a common enough pattern is to use list structure as if
it were a struct, with constructors and accessor methods that hide the
implementation details:

    (defun make-complex (x y) (cons 'complex (cons x y))
    (defun complex-x (c) (and (eq 'complex (car c)) (cadr c)))
    (defun complex-y (c) (and (eq 'complex (car c)) (cddr c)))

That is, the c*r methods are good and useful predefined accessors, but
you give them appropriate names so that you're not using them
directly. That way you don't make your users remember how to use these
generic accessors with your custom data type.

db48x

Re: lengths and other stuff

[Stefan Monnier]

> Definitely. But a common enough pattern is to use list structure as if
> it were a struct, with constructors and accessor methods that hide the
> implementation details:

And these are advantageously replaced by `cl-defstruct`.


        Stefan

Re: lengths and other stuff

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 15:05, Daniel Brooks <db48x@db48x.net> wrote:
> Some of them can no doubt be replaced by multiple-value-bind and other
> such things. This one from ido.el:1518, for example:
>
>     (if (and (listp (car l))
>              (> (length (car l)) 2)
>              (let ((dir (car (car l)))
>                    (time (car (cdr (car l))))
>                    (files (cdr (cdr (car l)))))
>
> could be (multiple-value-bind (dir time files) (car l) …).
>
> But those kinds of improvements take a lot more thought about each
> occurrence.

Very good.  Now the other ~1700 cases.

I think you introduced two bugs:

1) missing &rest, it should be:

   (multiple-value-bind (dir time &rest files) (car l) …)

2) multiple-value-bind throws an error if it does not fit.  The original
   code does not seem to throw an error.

But all this excercise for single case took mental effort, got it wrong
and the change would need to be carefully undertaken.

The point of the predicates is to avoid such rewrites and improve the
code simply by search, replace and visual substitution without thinking
hard and introducing bugs.

Re: lengths and other stuff

[Daniel Brooks]

Tomas Hlavaty <tom@logand.com> writes:

> On Sun 27 Dec 2020 at 15:05, Daniel Brooks <db48x@db48x.net> wrote:
>> Some of them can no doubt be replaced by multiple-value-bind and other
>> such things. This one from ido.el:1518, for example:
>>
>>     (if (and (listp (car l))
>>              (> (length (car l)) 2)
>>              (let ((dir (car (car l)))
>>                    (time (car (cdr (car l))))
>>                    (files (cdr (cdr (car l)))))
>>
>> could be (multiple-value-bind (dir time files) (car l) …).
>>
>> But those kinds of improvements take a lot more thought about each
>> occurrence.
>
> Very good.  Now the other ~1700 cases.
>
> I think you introduced two bugs:

I'm surprised that it was more than one!

db48x

Re: lengths and other stuff

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 15:35, Daniel Brooks <db48x@db48x.net> wrote:
> Tomas Hlavaty <tom@logand.com> writes:
>> I think you introduced two bugs:
>
> I'm surprised that it was more than one!

Not sure what do you mean.  The intention of the proposed predicates is
to improve code easily and not introduce any bugs.  You just showed that
your proposal cannot work.

Re: lengths and other stuff

[Daniel Brooks]

Tomas Hlavaty <tom@logand.com> writes:

> On Sun 27 Dec 2020 at 15:35, Daniel Brooks <db48x@db48x.net> wrote:
>> Tomas Hlavaty <tom@logand.com> writes:
>>> I think you introduced two bugs:
>>
>> I'm surprised that it was more than one!
>
> Not sure what do you mean.  The intention of the proposed predicates is
> to improve code easily and not introduce any bugs.  You just showed that
> your proposal cannot work.

I was agreeing with both you and Alfred. His point seemed to be that
length> is a bad idea because there are better alternatives. There are
often better alternatives but, as I pointed out, using them takes a lot
more thought. I didn't expect my use of multiple-value-bind to be
perfect, since I spent only a minute looking at the code and hadn't
tested it. I didn't expect anyone to write back five minutes later
to point out not one but two problems with it though!

I think length> and family are a good idea (though I would have gone
with the longer-than-p suggestion instead), but that it's also a good
idea to use alternatives when possible.

db48x

Re: Internationalize Emacs's messages (swahili)

[Alfred M. Szmidt]

   >    However, if somebody writes such code, it is almost trivial to fix
   >    it with search and replace:
   >
   >       "(= (length" -> "(length="
   >       "(< (length" -> "(length<"
   >       "(> (length" -> "(length>"
   >       "(/= (length" -> "(length/="
   >       "(<= (length" -> "(length<="
   >       "(>= (length" -> "(length>="
   >
   >    (plus extra closing paren)
   >
   > Users will assume that these length>= hacks will make their code
   > magically better, when they just hide a problematic form -- doing a
   > possibly complicated operation inside a predicate call.

   It will make their code better.  I do not see any magic there, it
   is pretty simple and logical.

I don't see how.  The pretense here is optimization, the user has to
be active no matter what even to discover these functions.  The two
functions are advertised as equal as well, so there is no possible way
for the user to know which one to use when, and it might be suprising
that the behaviour (in run time) is different.


If the two forms are exactly equivalent, then the bytecompiler should
be able to do the work instead of the user.


And is it just me, but I'd expect that length>, etc takes two or more
sequences and returns a boolean if one of sequence is
larger/smaller/equal/...

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 18:34, "Alfred M. Szmidt" <ams@gnu.org> wrote:
>    > Users will assume that these length>= hacks will make their code
>    > magically better, when they just hide a problematic form -- doing
>    > a possibly complicated operation inside a predicate call.
>
>    It will make their code better.  I do not see any magic there, it
>    is pretty simple and logical.
>
> I don't see how.

By not counting all the elements of the list.

By counting only the minimum necessary.

It is fascinating how many people with strong opinions do not understand
the problem with

   (> (length x) 2)

> The pretense here is optimization, the user has to be active no matter
> what even to discover these functions.

And?

And if they fail at that, someone can once in a while fix that easily by
search, replace and visual review without introducing bugs.

> The two functions are advertised as equal as well, so there is no
> possible way for the user to know which one to use when, and it might
> be suprising that the behaviour (in run time) is different.

Which two functions are advertised as equal?

Where is confusion and surprise?

> If the two forms are exactly equivalent, then the bytecompiler should
> be able to do the work instead of the user.
>
> And is it just me, but I'd expect that length>, etc takes two or more
> sequences and returns a boolean if one of sequence is
> larger/smaller/equal/...

Would not that be better called sequence>?

What does "sequence is larger/smaller/equal" mean exactly?

Re: Internationalize Emacs's messages (swahili)

[Alfred M. Szmidt]

   It is fascinating how many people with strong opinions do not understand
   the problem with

      (> (length x) 2)

You are assuming that X is always a list, there are far more types
than that in Emacs Lisp.  Replacing every instance of (PREDIATE
(length ...)) with (lengthPREDICATE ...) doesn't really do anything at
all for the cases where we are not working with a list -- which you
cannot possibly know just from a grep of the code.

   And if they fail at that, someone can once in a while fix that
   easily by search, replace and visual review without introducing
   bugs.

But nothing is fixed by such a change, thats the whole point, if you
are working with strings you are not fixing anything!  You are
introducing a gratious change that does absolutely nothing.

   > The two functions are advertised as equal as well, so there is no
   > possible way for the user to know which one to use when, and it might
   > be suprising that the behaviour (in run time) is different.

   Which two functions are advertised as equal?

Should have written forms, length> and (> (length ...), and the other
variants.

   > And is it just me, but I'd expect that length>, etc takes two or more
   > sequences and returns a boolean if one of sequence is
   > larger/smaller/equal/...

   Would not that be better called sequence>?

   What does "sequence is larger/smaller/equal" mean exactly?

(> 6 5 4 3 2 1) --> t
(length> '(1 2 3 4) '(1 2 3) '(1 2) '(1)) --> t

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 19:16, "Alfred M. Szmidt" <ams@gnu.org> wrote:
>    It is fascinating how many people with strong opinions do not
>    understand the problem with
>
>       (> (length x) 2)
>
> You are assuming that X is always a list,

I am not.

> there are far more types than that in Emacs Lisp.  Replacing every
> instance of (PREDIATE (length ...)) with (lengthPREDICATE ...) doesn't
> really do anything at all for the cases where we are not working with
> a list -- which you cannot possibly know just from a grep of the code.

I do not need to know.

I know that after the change, the good cases will stay good and the bad
cases will be improved.

>    And if they fail at that, someone can once in a while fix that
>    easily by search, replace and visual review without introducing
>    bugs.
>
> But nothing is fixed by such a change, thats the whole point, if you
> are working with strings you are not fixing anything!  You are
> introducing a gratious change that does absolutely nothing.

It is the first step towards improvement.

>    > The two functions are advertised as equal as well, so there is no
>    > possible way for the user to know which one to use when, and it
>    > might be suprising that the behaviour (in run time) is different.
>
>    Which two functions are advertised as equal?
>
> Should have written forms, length> and (> (length ...), and the other
> variants.

They compute the same thing differently.

Like these two forms compute the same thing differently:

(progn 1)

vs

(progn (sleep 10) 1)

>    > And is it just me, but I'd expect that length>, etc takes two or
>    > more sequences and returns a boolean if one of sequence is
>    > larger/smaller/equal/...
>
>    Would not that be better called sequence>?
>
>    What does "sequence is larger/smaller/equal" mean exactly?
>
> (> 6 5 4 3 2 1) --> t
> (length> '(1 2 3 4) '(1 2 3) '(1 2) '(1)) --> t

or even (I already mentioned that earlier):

(length> 5 '(1 2 3 4) '(1 2 3) 2.33 '(1 2) '(1) -42) --> t

But this is not so important. A simple two arg function would help to
fix most or all of the bad cases.

Ultimately, the person who implements this will decide.

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Tomas Hlavaty <tom@logand.com> writes:

> Ultimately, the person who implements this will decide.

It's already implemented and on the trunk.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: Internationalize Emacs's messages (swahili)

[Drew Adams]

> It's already implemented and on the trunk.  :-)

If it's like the C code posted here earlier then
it won't work for dotted or circular lists.
It'll do something, but not what one might hope.

I addressed this (in Lisp) in my previous mail.
If you insist on implementing this in C, at
least please consider doing something similar,
to handle these cases.

Re: Internationalize Emacs's messages (swahili)

[Alfred M. Szmidt]

   I know that after the change, the good cases will stay good and the bad
   cases will be improved.

So you are suggesting that one should change code just to change code?

RE: Internationalize Emacs's messages (swahili)

[Drew Adams]

> Yes, I think <, = and > are the ones that are nice to have.  The /=, <=
> and >= are trivial to express via the others, so I didn't go there.

I agree with Stefan.  If you insist on defining
such predicates, please just do it in Lisp.

(defun length> (xs n)
  "Return non-nil if length of sequence XS is greater than N."
  (if (consp xs)
      (nthcdr n xs)
    (> (length xs) n)))

(defun length< (xs n)
  " Return non-nil if length of sequence XS is less than N."
  (if (consp xs)
      (null (nthcdr (1- n) xs))
    (< (length xs) n)))

(defun length= (xs n)
  " Return non-nil if length of sequence XS is N."
  (if (consp xs)
      (let ((ys  (nthcdr (1- n) xs)))
        (and ys  (null (cdr ys))))
    (= (length xs) n)))

or similar...
___

Of course, those can give values for some inputs
where the list is dotted, and raise errors for others.

But so can the C implementation you showed for `length<',
IIUC.  And testing for a `proper-list-p' anyway means
traversing the full list.

This is another reason I'm not crazy about Emacs adding
and promoting such predicates.  Better for users to try
to DTRT in any particular case.  Promoting these is likely
to encourage blind use.

At a minimum, the doc should say that if you want to be
sure a returned value makes sense then be sure the list
arg is a proper list.
___

An alternative (better, IMO), is to have such predicates
always return a nil or non-nil value.  The following
definitions do that.

For these definitions a dotted list acts just like the
same list without the dot, i.e., an atomic last cdr Z
is treated like (Z).  So the dotted list (a b . c)
behaves for these predicates just like (a b c).

And they apparently work fine for circular lists also.

(defun length> (xs n)
  "Return non-nil if length of sequence XS is greater than N."
  (if (atom xs)
      (> (length xs) n)
    (condition-case nil
        (nthcdr n xs)
      (error nil))))

(defun length< (xs n)
  "Return non-nil if length of sequence XS is less than N."
  (if (atom xs)
      (< (length xs) n)
    (condition-case nil
        (null (nthcdr (1- n) xs))
      (error t))))

(defun length= (xs n)
  "Return non-nil if length of sequence XS is N."
  (if (atom xs)
      (= (length xs) n)
    (condition-case nil
        (let ((ys  (condition-case nil
                       (nthcdr (1- n) xs)
                     (error nil))))
          (and ys  (null (cdr ys))))
      (error t))))

RE: Internationalize Emacs's messages (swahili)

[Drew Adams]

> > +DEFUN ("length<", Flength_less, Slength_less, 2, 2, 0,
> 
> I went ahead and pushed this (along with > and =, which seems like a
> natural set).

Is this the set of C-code definitions you implemented?

https://repo.or.cz/emacs.git/blobdiff/714ca849ba658405ddde698cdc5836c4c9b289ca..0f790464d547dd57a857d88dab309b286067ac45:/src/fns.c

Let me say at the outset that I'm no expert in C code.

But it looks to me like this might have the problems
I spoke of wrt Lisp implementations that don't handle
dotted or circular lists correctly.  Is that the case?

For circular lists, it looks like you just raise an
error systematically.  To me, that's not as good as
it should be.  The Lisp definitions I provided work
fine for circular lists - their length is greater than
any numeric value, through ` most-positive-fixnum'.
(The function `nthcdr' is well-defined and performant
for a circular-list argument.)

For dotted lists, I cited the fact that simple Lisp
definitions of the `length(<|=|>)' predicates can
raise an error for some inputs and for other inputs
return the same length as if the last cdr were
wrapped in `list'.

IOW, the behavior is inconsistent: no consistent
notification (e.g. error) that the list is dotted;
silent answers as if the list were not dotted, in
~half the cases.

Does your C code have these problems also?

The Lisp definitions I posted don't have these
problems.  They handle circular and dotted lists
fine.  For dotted lists, the length returned is
always the same as what it would be for a proper
list equal to the dotted list but with the last
cdr wrapped in `list'.

I imagine that the same approach I used in Lisp
could be used in C, with no loss in performance
wrt the code you have.  But again, I'm no expert,
especially in C.

In case you missed the Lisp definitions I'm talking
about, they're at the end of this message:

https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg01850.html

RE: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Thu 31 Dec 2020 at 21:55, Drew Adams <drew.adams@oracle.com> wrote:
> The Lisp definitions I posted don't have these problems.  They handle
> circular and dotted lists fine.  For dotted lists, the length returned
> is always the same as what it would be for a proper list equal to the
> dotted list but with the last cdr wrapped in `list'.

The predicates are trying to fix cases where people use length.

(length '(1 2 . 3))
=>
Debugger entered--Lisp error: (wrong-type-argument listp 3)

RE: Internationalize Emacs's messages (swahili)

[Drew Adams]

> > The Lisp definitions I posted don't have these problems.  They handle
> > circular and dotted lists fine.  For dotted lists, the length returned
> > is always the same as what it would be for a proper list equal to the
> > dotted list but with the last cdr wrapped in `list'.
> 
> The predicates are trying to fix cases where people use length.
> 
> (length '(1 2 . 3))
> =>
> Debugger entered--Lisp error: (wrong-type-argument listp 3)

Yes.  And?

If we're defining predicates to check whether the
length of a list is <, =, or > some value, those
predicates should do something useful, or at least
something one might expect, for non-proper lists
as well, no?

If you check `length<' for a dotted list, whether
on purpose or not (e.g., knowing, not knowing or
not caring whether the list is proper), would you
really expect that a true/false value would be
returned and sometimes an error would be raised?

I think it's more useful for a reasonable value to
always be returned for that.  Or one could argue
that an error should always be raised for that.
But sometimes true/false and sometimes raise an
error?  Why would we choose a design like that?

RE: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Fri 01 Jan 2021 at 11:09, Drew Adams <drew.adams@oracle.com> wrote:
> If we're defining predicates to check whether the length of a list is
> <, =, or > some value, those predicates should do something useful, or
> at least something one might expect, for non-proper lists as well, no?

What exactly means "something one might expect"?

I expect the predicates to work on proper list and it should count the
number of cons cells in the list.

I do not expect the predicates to count the last cdr differently
depending on its value.

RE: Internationalize Emacs's messages (swahili)

[Drew Adams]

> > If we're defining predicates to check whether the length of a list is
> > <, =, or > some value, those predicates should do something useful, or
> > at least something one might expect, for non-proper lists as well, no?
> 
> What exactly means "something one might expect"?
> 
> I expect the predicates to work on proper list and
> it should count the number of cons cells in the list.
> 
> I do not expect the predicates to count the last cdr differently
> depending on its value.

The question iss not what the behavior should be
for proper lists.  The question is what it should
be for dotted lists (and circular lists).

What is your reasonable expectation for dotted lists?

I'd suggest these are two reasonable expectations
for a dotted-list length comparison against a number:

1. Always raise an error.
2. Never raise an error.

For #2, one reasonable expectation is, I think,
that the value returned always be true or false,
and exactly mirror the case for a proper list
whose last element is the last cdr of the dotted
list.

That has a good deal of consistency.  Non-nil
cdrs are simply counted (irrespective of their
non-nil values).  Nothing more happens.

(And the same can be said for a proper list:
the non-nil cdrs are counted - nothing more.)

"List" includes both proper and dotted lists.
Because a list can have a non-nil last cdr, it's
non-nil cdrs that I'd expect should be counted,
not cons cells.

But that's me.  To me, that behavior for dotted
lists would at least be of some _use_.  Always
raising an error for a dotted list is less useful.

But even if for some reason (what reason?) you
think #2 is _more_ useful, we don't even have #2.

The question really is, What behavior do you want
for a dotted list?

So far, the behavior is to sometimes (1) raise
an error and sometimes (2) return a true or false
value.  And there's little rhyme or reason for
when it does one or the other.

These use my Lisp definitions, which I guess do
what the current C code does for dotted lists:

(length> '(1 . 2) -1) ; true
(length> '(1 . 2) 0)  ; true
(length> '(1 . 2) 1)  ; true
(length> '(1 . 2) 2)  ; ---ERROR---
(length> '(1 . 2) 42) ; ---ERROR---

(length< '(1 . 2) -1) ; false
(length< '(1 . 2) 0)  ; false
(length< '(1 . 2) 1)  ; false
(length< '(1 . 2) 2)  ; false
(length< '(1 . 2) 24) ; ---ERROR---

(length= '(1 . 2) -1) ; false
(length= '(1 . 2) 0)  ; false
(length= '(1 . 2) 1)  ; false
(length= '(1 . 2) 2)  ; ---ERROR---
(length= '(1 . 2) 42) ; ---ERROR---

Is that really what you expect/want?  Not I.

I prefer that those ERROR cases return false
for >, and true for = and <.  Which is what
I implemented.

RE: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Fri 01 Jan 2021 at 14:55, Drew Adams <drew.adams@oracle.com> wrote:
> The question is what it should be for dotted lists (and circular
> lists).  What is your reasonable expectation for dotted lists?

I do not have an expectation for dotted lists except it should not
traverse the whole list in order to find out, if it is dotted or not.
That would defeat the whole idea.  It should do the minimum work
necessary to determine the predicate value and not bother with
determining if the list is dotted or circular.

RE: Internationalize Emacs's messages (swahili)

[Drew Adams]

> > The question is what it should be for dotted
> > lists (and circular lists).  What is your
> > reasonable expectation for dotted lists?
> 
> I do not have an expectation for dotted lists except it should not
> traverse the whole list in order to find out, if it is dotted or not.
> That would defeat the whole idea.  It should do the minimum work
> necessary to determine the predicate value and not bother with
> determining if the list is dotted or circular.

Nothing in what I've written just traverses the
whole list.

The point of this thread is to have predicates
that check whether the length of a list (or
sequence) is < = or > some number WITHOUT always
having to traverse it entirely to get the answer.

[Of course, if the answer to (length= foo 42)
is YES then `foo' will be visited to its end,
in some way (e.g. `nthcdr') or other.]

All I've suggested is that instead of throwing
an error we return the obvious answer for each
case.  That's no more work than actually throwing
the error, AFAIK.

Re: Internationalize Emacs's messages (swahili)

[Andreas Schwab]

On Dez 27 2020, Lars Ingebrigtsen wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> I whipped one up quickly.
>
> With this totally realistic benchmark, this is what we have today:
>
> (let ((list (make-list 10000 nil)))
>   (benchmark-run 1000000 (< (length list) 2)))
> => (10.826215101 0 0.0)
>
> The same, with length<:
>
> (let ((list (make-list 10000 nil)))
>   (benchmark-run 1000000 (length< list 2)))
> => (0.05590014099999999 0 0.0)
>
> If we avoid tortoise/hare for small LENGTHs, then it's about 20% faster
> than that again (if we're doing (length< list 200)).

Why do you need to reimplement nthcdr, badly?

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: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Why do you need to reimplement nthcdr, badly?

Because people say (if (= (length foo) 0)) all over the place, without
caring whether foo is a list, a string, or whatever, and I want them to
be able to say (if (length= foo 0)) with the same confidence and
convenience.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Andreas Schwab]

On Dez 27 2020, Lars Ingebrigtsen wrote:

> Because people say (if (= (length foo) 0)) all over the place, without
> caring whether foo is a list, a string, or whatever, and I want them to
> be able to say (if (length= foo 0)) with the same confidence and
> convenience.

So why do you need to reimplement nthcdr then, badly?

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: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> So why do you need to reimplement nthcdr then, badly?

I don't know -- you tell me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Andreas Schwab]

On Dez 27 2020, Lars Ingebrigtsen wrote:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> So why do you need to reimplement nthcdr then, badly?
>
> I don't know -- you tell me.

How do I know what you were thinking?

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: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>>> So why do you need to reimplement nthcdr then, badly?
>>
>> I don't know -- you tell me.
>
> How do I know what you were thinking?

I certainly don't know what you're thinking, but you enjoy being
cryptic, so that's pretty usual.

Or did you mean implement these functions by using Fnthcdr?  Sure,
that'd work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Andreas Schwab]

On Dez 27 2020, Lars Ingebrigtsen wrote:

> Or did you mean implement these functions by using Fnthcdr?  Sure,
> that'd work.

Of course, it will work.  There is absolutely no need to reimplement it,
badly.

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: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> Or did you mean implement these functions by using Fnthcdr?  Sure,
>> that'd work.
>
> Of course, it will work.  There is absolutely no need to reimplement it,
> badly.

If you'd said that in the first place, we could have saved ourselves
three back-and-fourths.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Andreas Schwab]

On Dez 27 2020, Lars Ingebrigtsen wrote:

> If you'd said that in the first place, we could have saved ourselves
> three back-and-fourths.

<jwvft3smepa.fsf-monnier+emacs@gnu.org>

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: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Dez 27 2020, Lars Ingebrigtsen wrote:
>
>> If you'd said that in the first place, we could have saved ourselves
>> three back-and-fourths.
>
> <jwvft3smepa.fsf-monnier+emacs@gnu.org>

Oops; I guess I forgot about that.  Mea culpa.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 23:30, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Dez 27 2020, Lars Ingebrigtsen wrote:
>
>> Or did you mean implement these functions by using Fnthcdr?  Sure,
>> that'd work.
>
> Of course, it will work.  There is absolutely no need to reimplement
> it, badly.

There are probably many ways to implement it.

I can even imagine not adding any of those predicates and make the
compiler more clever, maybe using some kind of compiler macro on the
= < > /= <= => predicates.
That way the existing code would not need to be changed at all.
But this is not Common Lisp so it is probably not an option here.

Re: Internationalize Emacs's messages (swahili)

[Lars Ingebrigtsen]

In terms of nthcdr, length< would look like this, and would work for
bignum values of LENGTH.  And it's 15% slower for the benchmark I'm
using:

(let ((list (make-list 10000 nil)))
  (benchmark-run 100000000 (length< list 200)))

DEFUN ("length<", Flength_less, Slength_less, 2, 2, 0,
       doc: /* Return non-nil if SEQUENCE is shorter than LENGTH.
See `length' for allowed values of SEQUENCE and how elements are
counted.  */)
  (Lisp_Object sequence, Lisp_Object length)
{
  if (CONSP (sequence))
    return Fnull (Fnthcdr (Fsub1 (length), sequence));
  else
    return CALLN(Flss, Flength (sequence), length);
}


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Internationalize Emacs's messages (swahili)

[Alfred M. Szmidt]

   > Why do you need to reimplement nthcdr, badly?

   Because people say (if (= (length foo) 0)) all over the place, without
   caring whether foo is a list, a string, or whatever, and I want them to
   be able to say (if (length= foo 0)) with the same confidence and
   convenience.

If the goal is to avoid writing bad code, then one should definitly
not be introducing something like length= as a means to evade it,
since both those forms are to be avoided.

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 17:32, "Alfred M. Szmidt" <ams@gnu.org> wrote:
>    Because people say (if (= (length foo) 0)) all over the place,
>    without caring whether foo is a list, a string, or whatever, and I
>    want them to be able to say (if (length= foo 0)) with the same
>    confidence and convenience.
>
> If the goal is to avoid writing bad code,

The goal is to avoid writing bad code and also to easily fix existing
bad code.

> then one should definitly not be introducing something like length= as
> a means to evade it, since both those forms are to be avoided.

Why?

Re: Internationalize Emacs's messages (swahili)

[Alfred M. Szmidt]

   On Sun 27 Dec 2020 at 17:32, "Alfred M. Szmidt" <ams@gnu.org> wrote:
   >    Because people say (if (= (length foo) 0)) all over the place,
   >    without caring whether foo is a list, a string, or whatever, and I
   >    want them to be able to say (if (length= foo 0)) with the same
   >    confidence and convenience.
   >
   > If the goal is to avoid writing bad code,

   The goal is to avoid writing bad code and also to easily fix existing
   bad code.

If (> (length foo) 10) is bad or not depends entierly on its context.

   > then one should definitly not be introducing something like length= as
   > a means to evade it, since both those forms are to be avoided.

   Why?

If foo is a list, then you should use null.  If foo is a string, you
should use string-empty-p.  If foo is some other, you should use that.

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 18:17, "Alfred M. Szmidt" <ams@gnu.org> wrote:
> If (> (length foo) 10) is bad or not depends entierly on its context.

(> (length foo) 10)

uselessly counts (max 0 (- (length foo) 10)) items (+/- off by one
error?)

(length> foo 10)

uselessly counts 0 items

>    > then one should definitly not be introducing something like
>    > length= as a means to evade it, since both those forms are to be
>    > avoided.
>
>    Why?
>
> If foo is a list, then you should use null.  If foo is a string, you
> should use string-empty-p.  If foo is some other, you should use that.

I do not use anything.

The bad code _is already_ in Emacs.

For new code, suggestions are nice, but will likely not bear much
fruits.

Also (if (null foo) ...) is ugly, (if foo ...) is much nicer.

Re: Internationalize Emacs's messages (swahili)

[Alfred M. Szmidt]

   > If (> (length foo) 10) is bad or not depends entierly on its context.

   (> (length foo) 10)

   uselessly counts (max 0 (- (length foo) 10)) items (+/- off by one
   error?)

There are more things in life than lists ...  length on a char-table
or a string is constant.

What is trying to be optimized here is not (PREDICATE (length ...))
but rather the implicit list-length, i.e. (PREDICATE (list-length
...)).

   The bad code _is already_ in Emacs.

Then that code should be fixed, it will be needed to be fixed anyway
-- a new function won't fix it magically.

Re: Internationalize Emacs's messages (swahili)

[Tomas Hlavaty]

On Sun 27 Dec 2020 at 18:55, "Alfred M. Szmidt" <ams@gnu.org> wrote:
>    (> (length foo) 10)
>
>    uselessly counts (max 0 (- (length foo) 10)) items (+/- off by one
>    error?)
>
> There are more things in life than lists

(elisp) Programming Tips

   • Use lists rather than vectors, except when there is a particular
     reason to use a vector.  Lisp has more facilities for manipulating
     lists than for vectors, and working with lists is usually more
     convenient.

     Vectors are advantageous for tables that are substantial in size
     and are accessed in random order (not searched front to back),
     provided there is no need to insert or delete elements (only lists
     allow that).

> ...  length on a char-table or a string is constant.

We are not trying to solve non-issue here.

>    The bad code _is already_ in Emacs.
>
> Then that code should be fixed, it will be needed to be fixed anyway
> -- a new function won't fix it magically.

Yes.  But that code will not fix itself magically on its own.  Somebody
will have to do it.  The new predicates address this need and will help
the person to do it easily and without introducing bugs.

Re: Internationalize Emacs's messages (swahili)

[Alfred M. Szmidt]

   >    (> (length foo) 10)
   >
   >    uselessly counts (max 0 (- (length foo) 10)) items (+/- off by one
   >    error?)
   >
   > There are more things in life than lists

   (elisp) Programming Tips

So we agree that Emacs has more types than lists.

   > ...  length on a char-table or a string is constant.

   We are not trying to solve non-issue here.

Did you check each case where length was used that it was actually on
a list?  If not, how can you possibly know that it is a non-issue?

   >    The bad code _is already_ in Emacs.
   >
   > Then that code should be fixed, it will be needed to be fixed anyway
   > -- a new function won't fix it magically.

   Yes.  But that code will not fix itself magically on its own.  Somebody
   will have to do it.  The new predicates address this need and will help
   the person to do it easily and without introducing bugs.

And broken code that does something stupid, will not get fixed by
length> or its equivalents.  If one wishes to actually fix code, one
cannot do so blindly..

Re: Internationalize Emacs's messages (swahili)

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2020-12-28 01:06]:
> Andreas Schwab <schwab@linux-m68k.org> writes:
> 
> > Why do you need to reimplement nthcdr, badly?
> 
> Because people say (if (= (length foo) 0)) all over the place, without
> caring whether foo is a list, a string, or whatever, and I want them to
> be able to say (if (length= foo 0)) with the same confidence and
> convenience.

That function could also test for second parameter if it is something
else but number to help in testing (length= list list) as well or
strings.

I will start using it.

(defun length= (seq arg)
  (if (numberp arg)
      (= (length seq) arg)
    (= (length seq) (length arg))))

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 26 Dec 2020 17:08:23 -0500
> 
> > Oh, sure.  But since this is a pure speed optimisation we're talking
> > about, the Lisp solution would be slower than the (< (length foo) bar)
> > in a significant number of cases, and we don't want that, do we?
> 
> Actually, AFAICT this all started from:
> 
>     (not (null (cdr deleted))) would avoid traversing the entire list,
>     but it wouldn't be easier to read.

No, it started from

  (> (length LIST) 1)

being a waste of cycles.

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 26 Dec 2020 16:45:52 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> I mean we can already easily implement those things in ELisp:

The argument for adding this functionality was performance.  So
implementing that in Lisp would mean we don't need to implement it at
all.

Re: Internationalize Emacs's messages (swahili)

[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 a `longer-than-p' function would be helpful?  I.e.,
  > (longer-than-p deleted 1)?  (Or some better name.)

That is a reasonable way to speed it up.
But if this is mainly to be used in connection with
user output, the speedup would be insignificant,
and thus not worth the cost of documenting it
and maintaining 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: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Daniel Brooks <db48x@db48x.net>
> Cc: Zhu Zihao <all_but_last@163.com>,  dimech@gmx.com,  abrochard@gmx.com,
>   rms@gnu.org,  bugs@gnu.support,  emacs-devel@gnu.org
> Date: Fri, 25 Dec 2020 18:03:21 -0800
> 
> My personal opinion is that gettext is too limited. It works for simple
> things, but provides no help at all for complex things.

That is in no way specific to Emacs, is it?

> I think that the most productive way to think about translation is that
> each coherent message that we present to a user (whether it's via the
> message function or not) should explicitly be the result of calling a
> function written by the translator. gettext only allows the translator
> to supply strings, so it falls down in complex situations.

The advantage of the translation infrastructure based on gettext is
that the translators don't have to be programmers, they only need to
be experts in correct use of technical terminology in their
languages.  Even with that significant advantage, it is hard to find
translators for many languages.  Your suggestion would make that job
much harder, with the net result that more messages for more programs
will remain untranslated: a classic example where the best is a sworn
enemy of the good.

(Disclosure: I'm the team leader for translators to the Hebrew
language, as part of the GNU Translation Project.  I'm talking from
personal experience here.)

> The classical example is the "You have 42 new messages." situation. With
> gettext, it is tempting to ask the translator to translate a string such
> as "You have %d new messages.", but this does not give them any
> flexibility to correctly handle languages with more plural categories
> than English. Russian, for example, has a plural category for all
> numbers that are one more than a multiple of ten except 11, which is a
> special case. It also has another category for all numbers ending in 2,
> 3, or 4 except for 12, 13, and 14. (I don't actually know Russian, but
> the rules are summarized in a page or two at
> <http://www.russianlessons.net/lessons/lesson11_main.php>.) There are
> over 7,700 distinct languages in the world, and we should assume that
> they are all at least that crazy. An ideal situation does not allow the
> craziness to leave the translation and make the implementation more
> complex. Nor should the craziness of Russian make writing a Spanish
> translation more difficult.

This problem was solved in gettext long ago, and is being widely used
in existing translations.  See the node "Plural Forms" in the GNU
gettext manual.  Emacs has the ngettext function in preparation for
the day when we will be able to have translatable message strings.

> I recommend taking a look at Project Fluent
> <https://www.projectfluent.org/>. It's a free-software implementation of
> exactly the system that I've described. Translators write functions in a
> syntax that is similar in some ways to both Javascript and an ini file,
> which could be easily compiled into Elisp. (It's the successor to the
> l20n project, which you might also have heard of.)

How many translated languages for how many programs does this project
have?

Anyway, the hard problems in translating some of the Emacs UI are
elsewhere, as can be seen from the discussions to which I pointed.  We
need to solve those first, and only after that worry about the issues
you mention (if they are real).

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Brooks <db48x@db48x.net>
>> Cc: Zhu Zihao <all_but_last@163.com>,  dimech@gmx.com,  abrochard@gmx.com,
>>   rms@gnu.org,  bugs@gnu.support,  emacs-devel@gnu.org
>> Date: Fri, 25 Dec 2020 18:03:21 -0800
>> 
>> My personal opinion is that gettext is too limited. It works for simple
>> things, but provides no help at all for complex things.
>
> That is in no way specific to Emacs, is it?

Absolutely.

>> I think that the most productive way to think about translation is that
>> each coherent message that we present to a user (whether it's via the
>> message function or not) should explicitly be the result of calling a
>> function written by the translator. gettext only allows the translator
>> to supply strings, so it falls down in complex situations.
>
> The advantage of the translation infrastructure based on gettext is
> that the translators don't have to be programmers, they only need to
> be experts in correct use of technical terminology in their
> languages.  Even with that significant advantage, it is hard to find
> translators for many languages.  Your suggestion would make that job
> much harder, with the net result that more messages for more programs
> will remain untranslated: a classic example where the best is a sworn
> enemy of the good.

Yes, the simplicity of gettext is a big point in its favor. In the
common case, Fluent is not much more complicated. Here's a file from the
en-US locale from Firefox:
https://searchfox.org/mozilla-central/source/browser/locales/en-US/browser/aboutDialog.ftl

Most of the complications here come from the html that is embedded
inside the localized text:

    update-failed-main = Update failed. <a data-l10n-name="failed-link-main">Download the latest version</a>

Another language might put different text before or after the link, so
the anchor tag has to be part of the localized text. However, the
Javascript that displays this text will add the href to the anchor
first.

> (Disclosure: I'm the team leader for translators to the Hebrew
> language, as part of the GNU Translation Project.  I'm talking from
> personal experience here.)
>

> This problem was solved in gettext long ago, and is being widely used
> in existing translations.  See the node "Plural Forms" in the GNU
> gettext manual.  Emacs has the ngettext function in preparation for
> the day when we will be able to have translatable message strings.

Yes, I am aware of ngettext, and I could have picked a different
example. Consider the example from projectfluent.org, where the output
should change based on the user's gender:

    shared-photos =
        {$userName} {$photoCount ->
            [one] added a new photo
           *[other] added {$photoCount} new photos
        } to {$userGender ->
            [male] his stream
            [female] her stream
           *[other] their stream
        }.

This one produces messages like "Anne⁩ ⁨added ⁨3⁩ new photos⁩ to ⁨her
stream⁩.", which vary based on the three inputs passed in. ngettext
handles plurals, but it doesn't generalize to any other type of
variation we might want. I can't think of any reason why Emacs would
care about gender, but maybe BBDB could.

Another example from fluentproject.org illustrates that individual
translations can add variations that are purely for their own use.

The English translation has "-sync-brand-name = Firefox Account", which
is just assigning static text to a variable which will use used
frequently.

The Italian translation changes it to this:

    -sync-brand-name = {$first ->
       *[uppercase] Account Firefox
        [lowercase] account Firefox
    }

which serves the same purpose but lets the translator put this text at
both the beginning and end of a sentence.

Meanwhile, the Polish translator has changed it to this:

    -sync-brand-name = {$case ->
       *[nominative] Konto Firefox
        [genitive] Konta Firefox
        [accusative] Kontem Firefox
    }

which lets them choose the correct declension when needed:

    sync-signedout-title = Zaloguj do {-sync-brand-name(case: "genitive")}

All three translations can do their own thing, without needing to ask
the UI implementer to change anything and without coordinating with each
other first. They can also add these features gradually, as they refine
the translation. For example, they can start with a form that partly
dodges the grammar like "New emails: 42" at first, then later refine it
to "Found 42 new emails" once they get better coverage.

>> I recommend taking a look at Project Fluent
>> <https://www.projectfluent.org/>. It's a free-software implementation of
>> exactly the system that I've described. Translators write functions in a
>> syntax that is similar in some ways to both Javascript and an ini file,
>> which could be easily compiled into Elisp. (It's the successor to the
>> l20n project, which you might also have heard of.)
>
> How many translated languages for how many programs does this project
> have?

The main one that I know of is Firefox, which by my count has 96
translations. (See
<https://www.mozilla.org/en-US/firefox/all/#product-desktop-release>.)

> Anyway, the hard problems in translating some of the Emacs UI are
> elsewhere, as can be seen from the discussions to which I pointed.  We
> need to solve those first, and only after that worry about the issues
> you mention (if they are real).

I think that a system like Fluent moves most of the problems into the
translations, where they are more tractable (because each translation
only has to solve it's own problems). Note that most of Firefox's
translations are maintained by voluteers. They don't even have to send
patches or commit files to version control; they use a web page to view
and edit the translation, as well as to preview the results live. The
same tools can be used for Emacs.

I will continue to peruse these previous threads that you've pointed
out, but I'm not aware of anything that would be harder than just going
through the code factoring out the text. There aren't any clever macros
that can help with that, just hard work.

db48x

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Daniel Brooks <db48x@db48x.net>
> Cc: all_but_last@163.com,  bugs@gnu.support,  dimech@gmx.com,
>   abrochard@gmx.com,  emacs-devel@gnu.org,  rms@gnu.org
> Date: Sat, 26 Dec 2020 01:07:50 -0800
> 
> Yes, I am aware of ngettext, and I could have picked a different
> example. Consider the example from projectfluent.org, where the output
> should change based on the user's gender:

I think this issue is largely irrelevant to Emacs (and to translating
program messages in general), since it customary nowadays to avoid
gender-specific language.  We certainly do that in Emacs.

> > How many translated languages for how many programs does this project
> > have?
> 
> The main one that I know of is Firefox, which by my count has 96
> translations.

I didn't mean one program, I meant the total count.  It should be
indicative to how easy it is to find people who are both programmers
and can succinctly express themselves on technical issues in their
native languages.  IME, it is very hard to find such people.

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Brooks <db48x@db48x.net>
>> Cc: all_but_last@163.com,  bugs@gnu.support,  dimech@gmx.com,
>>   abrochard@gmx.com,  emacs-devel@gnu.org,  rms@gnu.org
>> Date: Sat, 26 Dec 2020 01:07:50 -0800
>> 
>> Yes, I am aware of ngettext, and I could have picked a different
>> example. Consider the example from projectfluent.org, where the output
>> should change based on the user's gender:
>
> I think this issue is largely irrelevant to Emacs (and to translating
> program messages in general), since it customary nowadays to avoid
> gender-specific language.  We certainly do that in Emacs.

Agreed, which is why I went on with the other example. The main point is
that it is generalizable to other kinds of variation besides just
plurals. Gettext does plurals, but nothing else.

>> > How many translated languages for how many programs does this project
>> > have?
>> 
>> The main one that I know of is Firefox, which by my count has 96
>> translations.
>
> I didn't mean one program, I meant the total count.  It should be
> indicative to how easy it is to find people who are both programmers
> and can succinctly express themselves on technical issues in their
> native languages.  IME, it is very hard to find such people.

I don't know the full count, I only know that Mozilla uses it for
Firefox as well as all of their web pages, and that most of those
translations are maintained by volunteers. Those volunteers are clearly
capable of doing the job, since there are 96 actively-maintained
translations for Firefox, which is a complex application which is hard
to translate. I think we can find similarly-capable volunteers to help
translate Emacs once the infrastructure is in place. I don't think most
of those people will already know either gettext or fluent
syntax. They'll learn as they go, just like the rest of us do.

db48x

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> From: Daniel Brooks <db48x@db48x.net>
> Cc: rms@gnu.org,  bugs@gnu.support,  dimech@gmx.com,  abrochard@gmx.com,
>   emacs-devel@gnu.org,  all_but_last@163.com
> Date: Sat, 26 Dec 2020 01:37:43 -0800
> 
> >> The main one that I know of is Firefox, which by my count has 96
> >> translations.
> >
> > I didn't mean one program, I meant the total count.  It should be
> > indicative to how easy it is to find people who are both programmers
> > and can succinctly express themselves on technical issues in their
> > native languages.  IME, it is very hard to find such people.
> 
> I don't know the full count, I only know that Mozilla uses it for
> Firefox as well as all of their web pages, and that most of those
> translations are maintained by volunteers. Those volunteers are clearly
> capable of doing the job, since there are 96 actively-maintained
> translations for Firefox, which is a complex application which is hard
> to translate.

Being able to program for one project in that project's programming
language doesn't mean the same people can do that for another project
written in a different PL.  That's the main disadvantage of your
proposal: you require the translators to be proficient as programmers
in the project's PL, not just in their language.

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Eli Zaretskii <eliz@gnu.org> writes:

> Being able to program for one project in that project's programming
> language doesn't mean the same people can do that for another project
> written in a different PL.  That's the main disadvantage of your
> proposal: you require the translators to be proficient as programmers
> in the project's PL, not just in their language.

No, it would require no knowledge of Elisp at all. Learning Fluent isn't
going to be any more difficult than learning gettext; the simple cases
are actually simpler in Fluent, and the complex cases (handling
variations) is much simpler in Fluent than in gettext.

db48x

Re: Internationalize Emacs's messages (swahili)

[Werner LEMBERG]

>> I didn't mean one program, I meant the total count.  It should be
>> indicative to how easy it is to find people who are both
>> programmers and can succinctly express themselves on technical
>> issues in their native languages.  IME, it is very hard to find
>> such people.
> 
> I don't know the full count, I only know that Mozilla uses it for
> Firefox as well as all of their web pages, and that most of those
> translations are maintained by volunteers.  [...]

Just curious: Does 'fluent' support (E)lisp and/or Scheme?


    Werner

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Werner LEMBERG <wl@gnu.org> writes:

> Just curious: Does 'fluent' support (E)lisp and/or Scheme?

Not specifically. I envision having a simple compiler written in elisp
that turns fluent into elisp functions, or some other form that can be
loaded when needed.

db48x

Re: Internationalize Emacs's messages (swahili)

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-26 12:32]:
> I think this issue is largely irrelevant to Emacs (and to translating
> program messages in general), since it customary nowadays to avoid
> gender-specific language.  We certainly do that in Emacs.

In many languages nouns have its gender classes, and I hope you do not
mean that. Example is that flower in German is refered as female while
in some other languages as male.

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Jean Louis <bugs@gnu.support> writes:

> * Eli Zaretskii <eliz@gnu.org> [2020-12-26 12:32]:
>> I think this issue is largely irrelevant to Emacs (and to translating
>> program messages in general), since it customary nowadays to avoid
>> gender-specific language.  We certainly do that in Emacs.
>
> In many languages nouns have its gender classes, and I hope you do not
> mean that. Example is that flower in German is refered as female while
> in some other languages as male.

The example I used was dealing with the gender of a user, rather than of
a random noun. Emacs itself doesn't talk about the user very much,
though in principle I could see someone using BBDB to keep track of the
gender of their contacts. Regardless, Fluent can handle either type of
linguistic gender with equal ease, as well as all other types of variation.

db48x

Re: Internationalize Emacs's messages (swahili)

[Jean Louis]

* Daniel Brooks <db48x@db48x.net> [2020-12-26 13:15]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Eli Zaretskii <eliz@gnu.org> [2020-12-26 12:32]:
> >> I think this issue is largely irrelevant to Emacs (and to translating
> >> program messages in general), since it customary nowadays to avoid
> >> gender-specific language.  We certainly do that in Emacs.
> >
> > In many languages nouns have its gender classes, and I hope you do not
> > mean that. Example is that flower in German is refered as female while
> > in some other languages as male.
> 
> The example I used was dealing with the gender of a user, rather than of
> a random noun. Emacs itself doesn't talk about the user very much,
> though in principle I could see someone using BBDB to keep track of the
> gender of their contacts. Regardless, Fluent can handle either type of
> linguistic gender with equal ease, as well as all other types of variation.

Do you mean to teach computer to recognize gender of the user by the
user's name? That would not be a good guess.

What is possible is to let the user specify the gender and then
computer may construct gender relevant sentences.

Those titles such as Mrs. Mr. Ms. are more social titles, I use them
to recognie the social titles of people, but I do not consider them
equal to gender.

The only reasonable recognition of gender would be in a medical
database where people need to know something about that, or in dating
terms when one wish to mate with specific gender. Otherwise is more or
less useless.

Re: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Jean Louis <bugs@gnu.support> writes:

> * Daniel Brooks <db48x@db48x.net> [2020-12-26 13:15]:
>> Jean Louis <bugs@gnu.support> writes:
>> 
>> > * Eli Zaretskii <eliz@gnu.org> [2020-12-26 12:32]:
>> >> I think this issue is largely irrelevant to Emacs (and to translating
>> >> program messages in general), since it customary nowadays to avoid
>> >> gender-specific language.  We certainly do that in Emacs.
>> >
>> > In many languages nouns have its gender classes, and I hope you do not
>> > mean that. Example is that flower in German is refered as female while
>> > in some other languages as male.
>> 
>> The example I used was dealing with the gender of a user, rather than of
>> a random noun. Emacs itself doesn't talk about the user very much,
>> though in principle I could see someone using BBDB to keep track of the
>> gender of their contacts. Regardless, Fluent can handle either type of
>> linguistic gender with equal ease, as well as all other types of variation.
>
> Do you mean to teach computer to recognize gender of the user by the
> user's name? That would not be a good guess.

No, no. Go back and look at the example I used; the user's gender was an
input. The user in that example has chosen their own gender, and the
translation can use that to output the grammatically correct
sentence. As I said, it's not super relevant to Emacs. I only included
it to show that Fluent handles all variations the same way, whether it's
plurals or gender or declension.

db48x

Re: Internationalize Emacs's messages (swahili)

[Eli Zaretskii]

> Date: Sat, 26 Dec 2020 12:59:51 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> * Eli Zaretskii <eliz@gnu.org> [2020-12-26 12:32]:
> > I think this issue is largely irrelevant to Emacs (and to translating
> > program messages in general), since it customary nowadays to avoid
> > gender-specific language.  We certainly do that in Emacs.
> 
> In many languages nouns have its gender classes

I don't see how this is relevant to the issue at hand.  If I'm missing
something, please tell what that is.

Re: Internationalize Emacs's messages (swahili)

[Juri Linkov]

> Emacs has the ngettext function in preparation for the day
> when we will be able to have translatable message strings.

We are still waiting for someone knowable of gettext to install the
gettext framework for translation of texts in C.  Adapting gettext
bindings to Lisp messages and UI would be more trivial to do.

Re: Internationalize Emacs's messages (swahili)

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

  > My personal opinion is that gettext is too limited. It works for simple
  > things, but provides no help at all for complex things.

That is true.

  > I think that the most productive way to think about translation is that
  > each coherent message that we present to a user (whether it's via the
  > message function or not) should explicitly be the result of calling a
  > function written by the translator.

That could be acceptable if it is designed such that the functions
are so limited that there are no insecurities.

For GNU to use it, we would want it to fit into the framework
of gettext.  We could have a new function that programs should call,
which would look for a function encoded in the translation string.

Would you please email me the most important parts of the description
of Project Fluent?  So I don't have to hunt for them?



-- 
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: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Richard Stallman <rms@gnu.org> writes:

>   > My personal opinion is that gettext is too limited. It works for simple
>   > things, but provides no help at all for complex things.
>
> That is true.
>
>   > I think that the most productive way to think about translation is that
>   > each coherent message that we present to a user (whether it's via the
>   > message function or not) should explicitly be the result of calling a
>   > function written by the translator.
>
> That could be acceptable if it is designed such that the functions
> are so limited that there are no insecurities.

That's a good point. The Fluent "language" does only string
substitution, switch statements that choose amongst a set of strings,
and calling functions pre-defined by the program being translated. That
makes it easy to compile into safe code, or to produce a database that
can interpreted quickly.

> For GNU to use it, we would want it to fit into the framework
> of gettext.  We could have a new function that programs should call,
> which would look for a function encoded in the translation string.

I haven't considered that possibility, but my first impression is that
mashing them together might not be a good idea.

> Would you please email me the most important parts of the description
> of Project Fluent?  So I don't have to hunt for them?

Sure. The blurb on the FLuent website says this:

* Asymmetric Localization
  Natural-sounding translations with genders[1] and grammatical cases
  only when necessary. Expressiveness is not limited by the grammar of
  the source language.

* Progressive Enhancement
  Translations are isolated; locale-specific logic doesn't leak to other
  locales. Authors can iteratively improve translations without impact
  on other languages.

* Fully-Featured
  Date, time, and number formatting. Plural categories. Bidirectionality
  support. Custom formatters. Easy-to-read syntax. Runtime translation
  and re-translation. Robust error handling.

* Open Source
  Fluent Syntax 1.0 was released in April 2019. Client- and server-side
  implementations in JS, Python, and Rust. React bindings. Licensed
  under the Apache 2.0 License[2].

[1]: This includes both the genders of people and the genders of random
nouns in the translation. It also handles other sources of variation
such as plurals, declensions, inflections, and so on.

[2]: Aka, it's Free Software too.

db48x

Re: Internationalize Emacs's messages (swahili)

[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 the idea of integrating Fluent with gettext is interesting.
Would you like to study that possibility?

It seems that Fluent is not self-contained but rather depends
on the presence of an interpreter for JS, Python, or Rust.
Is that correct?  That would be very undesirable in C programs
that don't contain any interpreter (and don't need one).

Is it feasible to write a small Fluent interpreter in C for this
purpose?


-- 
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: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Richard Stallman <rms@gnu.org> writes:

> I think the idea of integrating Fluent with gettext is interesting.
> Would you like to study that possibility?

Yes, I have been considering it.

The biggest disconnect between Fluent and gettext is that Fluent allows
recursive substitutions and multiple substitutions per message. Even
just the fact that fluent handles the substitutions itself instead of
making the caller delegate to printf is a big difference. Each message
needs to give names to the values that will be substituted into it
(basically argument names), and the PO files would have to specify how
to use those arguments, whether it's subtituting them into the message
directly, or switching on their values.

The message catalog files (MO files) just have flat strings with no
notion of substitutions or function calls. This is why my first
inclination was to generate elisp code from a Fluent file.

The easiest way to mush gettext and fluent together is to put some
syntax into the messages that is post-processed before being returned to
the caller, turning it into an interpreter. Something like this in a PO
file:

msgid "-sync-brand-name"
msgstr "Firefox Account"

msgid "sync-signedout-title"
msgstr "Connect with your {-sync-brand-name}"

A hypothetical igettext function could look for the curly braces,
recurse to find the value of the -sync-brand-name message, perform the
substitution (which allocates a new string), and then return the
result. Or the value of sync-signedout-title could be precomputed before
it was stored in the MO file. For this simple example, either would
work.

But consider a more complicated scenario:

msgid "tabs-close-tooltip"
msgstr "{$tabCount ->
    [one] Zamknij kartę
    [few] Zamknij {$tabCount} karty
   *[many] Zamknij { $tabCount } kart
}"

Again igettext can process this after retrieving it from the MO file,
but again it's just turning it into an interpreter for a slightly lispy
language. It could be partially unrolled into the MO file by using up
multiple strings in the MO file, but it would still need to be an
interpreter to substitute in the tabCount value. Good translations
frequently have more complexity.

I'd rather it were compiled to elisp that can be byte-compiled and
hopefully jit-compiled before too long.

Also, note that the original language wants to have the same
substitution capabilities as the translations. To my mind it would be
really weird to embed those in the source of the program that uses
igettext. Consider the following hypothetical example:

(message (igettext "{$tabCount ->
    [one] Zamknij kartę
    [few] Zamknij {$tabCount} karty
   *[many] Zamknij { $tabCount } kart
}" 42))

The PO file would look something like this:

msgid "{$tabCount ->
    [one] Zamknij kartę
    [few] Zamknij {$tabCount} karty
   *[many] Zamknij { $tabCount } kart
}"
msgstr "{$tabCount ->
    [one] Close { $tabCount } tab
   *[many] Close { $tabCount } tabs
}"

This may be really weird for the translator, because it seems to imply
that the degree and type of abstractions used in the translation is
supposed to match that of the original text, which is not necessary at
all. Thus I have kept the Fluent convention of using simple textual
identifiers in the source code, which is a departure from the way
gettext is normally used.

My thoughts have gotten more organized as I wrote this up, so I
apologize if I've skipped any important deductive steps or otherwise
left anything unclear.

> It seems that Fluent is not self-contained but rather depends
> on the presence of an interpreter for JS, Python, or Rust.
> Is that correct?  That would be very undesirable in C programs
> that don't contain any interpreter (and don't need one).

Not quite. It's intended that various programs would either integrate
with an existing implementation, or implement the Fluent spec in their
own language where that's not convenient.

For example, a C program can link against the fluent-rs static library,
and thus avoid writing that code themselves. Of course depending on two
compilers (one for C and another for Rust, since fluent-rs is written in
Rust) is sometimes a deal-breaker.

I think we would ignore these existing implementations, except possibly
as a source of inspiration, and write our own.

> Is it feasible to write a small Fluent interpreter in C for this
> purpose?

Absolutely, but my personal preference is to write it in Elisp.

My second choice is actually to link against fluent-rs; Rust is a
great language and certainly better than C for implementing such
things. Of course that is it's own can of worms.

My third choice is to write an implementation in C. This we could
reasonably make a separate library we could share with anyone else
wanting to use Fluent in their C program. But then we would have to
write a lot of C.

db48x

Re: Internationalize Emacs's messages (swahili)

[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 it feasible to write a small Fluent interpreter in C for this
  > > purpose?

  > Absolutely, but my personal preference is to write it in Elisp.

An implementation in Elisp could be ok for Emacs, but Emacs is just
one of hundreds of GNU packages, and one of thousands of packages in
the GNU system.

To fully adopt Fluent along with gettext as the GNU method of handling
this, we need to make it work in C programs.  The only simple, clean
and general way is to implement it in C.

Maintainers will never adopt this if their programs need to link
with Emacs or with Rust.

  > The message catalog files (MO files) just have flat strings with no
  > notion of substitutions or function calls. This is why my first
  > inclination was to generate elisp code from a Fluent file.

I don't follow how the beginning leads to the conclusion.

  > The easiest way to mush gettext and fluent together is to put some
  > syntax into the messages that is post-processed before being returned to
  > the caller, turning it into an interpreter.

That is too terse for me -- I am totally list.

                                                Something like this in a PO
  > file:

  > msgid "-sync-brand-name"
  > msgstr "Firefox Account"

  > msgid "sync-signedout-title"
  > msgstr "Connect with your {-sync-brand-name}"

I see what it says, but can you explain how that relates to "syntax
that is post-processed before being returned to the caller"?  Terse
references such as "the caller" leave me lost because I can't tell
what they refer to.  The leap is too long for me to follow.

  > Also, note that the original language wants to have the same
  > substitution capabilities as the translations.

What does "the original language" mean here?

-- 
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: making gettext more like fluent

[Daniel Brooks]

Richard Stallman <rms@gnu.org> writes:

>   > > Is it feasible to write a small Fluent interpreter in C for this
>   > > purpose?
>
>   > Absolutely, but my personal preference is to write it in Elisp.
>
> An implementation in Elisp could be ok for Emacs, but Emacs is just
> one of hundreds of GNU packages, and one of thousands of packages in
> the GNU system.
>
> To fully adopt Fluent along with gettext as the GNU method of handling
> this, we need to make it work in C programs.  The only simple, clean
> and general way is to implement it in C.
>
> Maintainers will never adopt this if their programs need to link
> with Emacs or with Rust.

Certainly most programs cannot link to Emacs; Emacs isn't even designed
for that. Rust _is_ designed to be linked with C programs, and it is an
excellent language to write things in. It is only my opinion, but Rust
is a significant long-term threat to the ubiquity of GCC. Another
similar threat is the low quality of the C language itself. To counter
this, GCC should grow a Rust front-end. I hope that the work has already
begun.

But that is a topic for a different day.

I would not volunteer to write any large amount of C. I know C, and am
good enough with it, but suffering the aggravations of the language is
not my idea of a good time.

Again it's just my opinion, but Emacs could link against Rust code such
as fluent-rs if we wanted it to. The Rust compiler is free software, and
has become readily available in most Linux distributions. There are no
technical roadblocks either. I have no idea what it would take for
people to want it, but I'd volunteer to help if they did.

>   > The message catalog files (MO files) just have flat strings with no
>   > notion of substitutions or function calls. This is why my first
>   > inclination was to generate elisp code from a Fluent file.
>
> I don't follow how the beginning leads to the conclusion.

My apologies. It seems that I stated some of my conclusions and then
followed them up with supporting examples.

>   > The easiest way to mush gettext and fluent together is to put some
>   > syntax into the messages that is post-processed before being returned to
>   > the caller, turning it into an interpreter.
>
> That is too terse for me -- I am totally list.
>
>   > Something like this in a PO file:
>
>   > msgid "-sync-brand-name"
>   > msgstr "Firefox Account"
>
>   > msgid "sync-signedout-title"
>   > msgstr "Connect with your {-sync-brand-name}"
>
> I see what it says, but can you explain how that relates to "syntax
> that is post-processed before being returned to the caller"?  Terse
> references such as "the caller" leave me lost because I can't tell
> what they refer to.  The leap is too long for me to follow.

The caller is some part of Emacs, let's say. Emacs calls the hypthetical
igettext("sync-signedout-title"), and the translator wants Emacs to get
the string "Connect with your Firefox Account" (I've just copied this
example from projectfluent.org, which got it from the Firefox source
code). With this simple proposed syntax, igettext must inspect each
string that it retrieves from the message catalog to see if it contains
any substitutions. Those substitutions can be almost as recursive as a
real lisp program, and they can have conditional statements like lisp
programs.

Thus I would prefer to just compile the Fluent syntax into Lisp
functions rather than to write a new interpreter. One build step for
Emacs would be to read in the Fluent files for all available
translations, and output ordinary .el files. Those .el files would then
be loaded during the bootstrap process, just like all the existing lisp
source files.

It occurs to me that one way to refine this a little bit would be to
directly output a elisp bytecode to a .elc file after reading in a
Fluent file. This skips a step, and makes distributing packages
containing translations easier. Making `load' recognize Fluent files
seems like it would tie everything up nicely.

>   > Also, note that the original language wants to have the same
>   > substitution capabilities as the translations.
>
> What does "the original language" mean here?

Whatever language the user interface was originally written in. In the
case of Emacs, this is English.

The English "translation" of Emacs will want to use the same Fluent
capabilities that any translation would have access to.

db48x

Re: making gettext more like fluent

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

  > Thus I would prefer to just compile the Fluent syntax into Lisp
  > functions rather than to write a new interpreter.

Fluent offers a possible way of improving translation handling for the
whole GNU system.  That's what's really exciting.  It would make no
sese to do as much effort, or perhaps even more, to get support for
Emacs only and no other programs.

Rust is not an option for the GNU system.  It has to be C.

I will bring this up in gnu-prog-discuss when I dig up the
link about Fluent from the previous messages.

Is Fluent a trademark?  Is there a trademark license in Fluent?
If so, could you please send me the full text of that, as well as its URL?


-- 
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: making gettext more like fluent

[Daniel Brooks]

Richard Stallman <rms@gnu.org> writes:

>   > Thus I would prefer to just compile the Fluent syntax into Lisp
>   > functions rather than to write a new interpreter.
>
> Fluent offers a possible way of improving translation handling for the
> whole GNU system.  That's what's really exciting.  It would make no
> sese to do as much effort, or perhaps even more, to get support for
> Emacs only and no other programs.

In principle I agree.

> Rust is not an option for the GNU system.  It has to be C.

In practice, I find it sad that you would tie the success of GNU to the
fashion for a single programming language. C has been successful so far,
and has lent that success to GNU, but it seems unusual to decide that
the GNU project could never embrace another language and allow it to
become coequal with C. But of course it's not my decision.

> I will bring this up in gnu-prog-discuss when I dig up the
> link about Fluent from the previous messages.

https://www.projectfluent.org/

> Is Fluent a trademark?  Is there a trademark license in Fluent?
> If so, could you please send me the full text of that, as well as its URL?

Good question; I'm not really sure. It's a Mozilla project, so I assume
it's like Firefox. I'll check.

db48x

Re: making gettext more like fluent

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

  > In practice, I find it sad that you would tie the success of GNU to the
  > fashion for a single programming language.

In general, I don't.  However, most GNU packages are written in C, or
C++, and that includes the gettext support that this ought to be
included in.  To use a different language there would risk complications,
and it is better to avoid them by writing that program in C.

The program must ne small enough that rewriting it is not a big hassle.

-- 
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: Internationalize Emacs's messages (swahili)

[Zhu Zihao]

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


Richard Stallman writes:

> To fully adopt Fluent along with gettext as the GNU method of handling
> this, we need to make it work in C programs.  The only simple, clean
> and general way is to implement it in C.
>
> Maintainers will never adopt this if their programs need to link
> with Emacs or with Rust.

Rust is able to generate C dynamic library, so we can link with it.

The dynamic library generated by Rust often statically link with its
Rust dependencies(unless that dependency is a C lib wrapper). So
it's not difficult for user to get it.

I can ask upstream whether they have interest in maintain a stable C
inteface, if they can help, we don't need to reinvent wheels.

You can take a look at librsvg[1] (from project GNOME). A SVG renderer
powered by Rust(and it's also used by Emacs currently)


[1]: https://gitlab.gnome.org/GNOME/librsvg
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Internationalize Emacs's messages (swahili)

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

  > Rust is able to generate C dynamic library, so we can link with it.

I am interested in understanding what that means.  Could you describe
in 10-20 lines what it means?  What is the input, what is the output,
and what software does the conversion?

  > You can take a look at librsvg[1] (from project GNOME). A SVG renderer
  > powered by Rust(and it's also used by Emacs currently)

That is not something I can feasibly do -- it would take an hour if
not several hours for me to learn the basic points.  So I hope
you will describe what I need to know in a brief summary.

But I think it would be a nuisance to make this a separate library.
It should be packaged with the support for getopt, and written in C so
we (the GNU Project) can easily maintain it.

From what I hear, Rust has a fundamental practical flaw: it is not
intended to be stable.  The developers want to keep changing it.
That's fine, in principle, but until they decided to make it stable,
we should write important code in some other language.

-- 
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: Internationalize Emacs's messages (swahili)

[Daniel Brooks]

Richard Stallman <rms@gnu.org> writes:

>   > Rust is able to generate C dynamic library, so we can link with it.
>
> I am interested in understanding what that means.  Could you describe
> in 10-20 lines what it means?  What is the input, what is the output,
> and what software does the conversion?

It's just like compiling C into a library, but it's the Rust compiler
that creates the library. Other programs can then link with the library
as if it had been written in C.

> From what I hear, Rust has a fundamental practical flaw: it is not
> intended to be stable.  The developers want to keep changing it.
> That's fine, in principle, but until they decided to make it stable,
> we should write important code in some other language.

Ah, a concrete objection. This isn't quite true. The language is indeed
evolving more quickly than C (which has at least four or five versions
now). Mozilla has committed to keeping the Rust compiler
backwards-compatible with all past Rust Editions, of which there are
currently two. Code written to the 2015 or 2018 editions of Rust will
remain compilable by all future versions of the Rust compiler. You can
also mix and match them; a program written in Rust 2018 can have
dependencies written in Rust 2015 and visa versa.

In practice it's not really different from choosing between c99, c11,
and the rest.

db48x

Re: Internationalize Emacs's messages (swahili)

[Zhu Zihao]

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


Richard Stallman writes:

> I am interested in understanding what that means.  Could you describe
> in 10-20 lines what it means?  What is the input, what is the output,
> and what software does the conversion?

I think I can write a simple demo to help you understand. ;) Please wait.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

The posibility to use Rust libraries with GNU Project softwares(e.g. link with Rust library)

[Zhu Zihao]

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


Richard Stallman writes:
> I am interested in understanding what that means.  Could you describe
> in 10-20 lines what it means?  What is the input, what is the output,
> and what software does the conversion?

Just create a small example to help you understand how Rust interact
with C. link here: https://github.com/cireu/jieba-cbinding-example

jieba-rs is a Chinese segmentation crate(crate means library). CJK
languages usually don't use space to separate words so somebody create a
library to do it.

Please see jieba_rustlib/Cargo.toml, we have `crate-type = ["cdylib"]` in
lib section, so cargo(the builder of Rust code, like make) will ask (rustc)rust
compiler to generate C dynamic libraries.

I write a simple interface in jieba_rustlib/src/lib.rs. See the function
with `unsafe extern "C"` and `#[no_magle]` mark, it's marked for FFI to
C.

There're several ways to expose Rust API to C. Some simple types(int,
uint) will have corresponding mappings. For complex type like struct, we
can use #[repr(C)], make the struct layout compatible with C, so C can
access struct directly. Or just use pointer, let C treat Rust struct as
opaque object and use exported function to use it.

I use both in this example, for Jieba struct(introduced by jieba-rs
crate), I use pointer, for hand-craft compat layer of Rust dynamic array
and C arrays, I use C-compatiable struct to expose extra
information(length and capacity) of array to C.

And we use cbindgen(https://github.com/eqrion/cbindgen) to generate C
header, and result in jieba_rustlib/jieba_rustlib.h.

Finally we have dynamic library and header, we just include header in c
source(see main.c) and link with library to craft our application. I use Makefile to
automate these steps.

```
chino@asus-laptop:/archive/gitrepos/jieba-rs-c-binding-example$ LANG=en_US.utf8 make
make -C jieba_rustlib libjieba_rustlib.so
make[1]: Entering directory '/archive/gitrepos/jieba-rs-c-binding-example/jieba_rustlib'
cargo build --release
    Finished release [optimized] target(s) in 0.01s
cp target/release/libjieba_rustlib.so ./
make[1]: Leaving directory '/archive/gitrepos/jieba-rs-c-binding-example/jieba_rustlib'
gcc main.c -Ijieba_rustlib -Ljieba_rustlib -Wl,-rpath=jieba_rustlib -ljieba_rustlib -o main
chino@asus-laptop:/archive/gitrepos/jieba-rs-c-binding-example$ ./main 
我
可以
吞下
玻璃
而
不伤
身体
```

> From what I hear, Rust has a fundamental practical flaw: it is not
> intended to be stable.  The developers want to keep changing it.

I think Rust will keep evolving. But not aggressively.

The latest Rust stable version is 1.48. When a software/library
released it's 1.0 version, usually means it's production ready.

Cargo(package manager and build system for Rust) have lock. Users can
lock their crates to ensure a reproducible build.

And Rust also introduce "Edition" for breaking
changes(https://doc.rust-lang.org/edition-guide/editions/index.html).
It's stable if user stick to a specific edition. Any updates in same
edition should not break your code failed to compile/failed to run(if
so, it's probably a compiler bug).

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: Internationalize Emacs's messages (swahili)

[Andy Moreton]

On Tue 29 Dec 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. ]]]
>
>   > Rust is able to generate C dynamic library, so we can link with it.
>
> I am interested in understanding what that means.  Could you describe
> in 10-20 lines what it means?  What is the input, what is the output,
> and what software does the conversion?

The suggestion above is to build a shared library (.so, .dll, etc), but
written in Rust instead of C. That requires a Rust toochain to compile
the code.

>   > You can take a look at librsvg[1] (from project GNOME). A SVG renderer
>   > powered by Rust(and it's also used by Emacs currently)
>
> That is not something I can feasibly do -- it would take an hour if
> not several hours for me to learn the basic points.  So I hope
> you will describe what I need to know in a brief summary.

Rust is a language that fits the same space as C does: a systems
language with minimal runtime support needed (so ok for embedded
targets). It has good interop with C, so Rust code and C code can call
each other directly without any complicated FFI or marshalling.

For the example SVG library, that allowed the authors to rewrite parts
of the C code in Rust for better type safety (to reduce the number of
security critical bugs) without changing the library ABI.

> But I think it would be a nuisance to make this a separate library.
> It should be packaged with the support for getopt, and written in C so
> we (the GNU Project) can easily maintain it.
>
> From what I hear, Rust has a fundamental practical flaw: it is not
> intended to be stable.  The developers want to keep changing it.
> That's fine, in principle, but until they decided to make it stable,
> we should write important code in some other language.

The language core is stable now, and current work is mostly on
stabilising libraries. Rust is a promising language, and while not yet
completely stable the pace of change is slowing as it matures. Many
projects are using Rust in production code.

Adding another toolchain to the dependencies for a project is a large
change. In addition, the Rust toolchains do not (yet) support many of
the targets that are supported by C toolchains.

    AndyM

Rust trademark problems - Re: Internationalize Emacs's messages (swahili)

[Jean Louis]

* Andy Moreton <andrewjmoreton@gmail.com> [2020-12-30 17:01]:
> On Tue 29 Dec 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. ]]]
> >
> >   > Rust is able to generate C dynamic library, so we can link with it.
> >
> > I am interested in understanding what that means.  Could you describe
> > in 10-20 lines what it means?  What is the input, what is the output,
> > and what software does the conversion?
> 
> The suggestion above is to build a shared library (.so, .dll, etc), but
> written in Rust instead of C. That requires a Rust toochain to compile
> the code.

It is also to note the freedom issues with Rust trademark as those are
similar to Firefox trademark issues.

From Hyperbola GNU/Linux-libre:
https://issues.hyperbola.info/index.php?do=details&task_id=736

Quote:

Uses that require explicit approval

Distributing a modified version of the Rust programming language or
the Cargo package manager and calling it Rust or Cargo requires
explicit, written permission from the Rust core team. We will usually
allow these uses as long as the modifications are (1) relatively small
and (2) very clearly communicated to end-users.

Selling t-shirts, hats, and other artwork or merchandise requires
explicit, written permission from the Rust core team. We will usually
allow these uses as long as (1) it is clearly communicated that the
merchandise is not in any way an official part of the Rust project and
(2) it is clearly communicated whether profits benefit the Rust
project.

Using the Rust trademarks within another trademark requires written
permission from the Rust core team except as described above.

Reference links:
https://www.rust-lang.org/en-US/legal.html
https://www.mozilla.org/en-US/foundation/trademarks/policy/
https://www.mozilla.org/en-US/foundation/trademarks/list/

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 21 Dec 2020 00:47:18 -0500
> Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
> 
>   > I wonder whether the survey stems from lack of vision of emacs
>   > admin and developers.  For instance, Gcc has a Development Plan.
>   > Suggestions for changes to the plan are discussed on the Gcc
>   > mailing list and can be approved or rejected by the Gcc Steering
>   > Committee. How about Emacs?
> 
> GCC has many developers who are paid by various companies.
> That makes it easier to make plans and actually carry them out.

There's another important difference.  GCC implements programming
languages defined by evolving standards that are developed by other
bodies.  The evolution of those language standards largely defines the
GCC development plans.  Other project, like GDB, Binutils, etc. have
similar traits: they support hardware and software standards developed
elsewhere.

But Emacs is its own standard, defined by what we put into it, it
depends very little on outside developments, and is only tangentially
affected by those external developments.  So those developments cannot
determine our plans anywhere near to how the next C++ Standard affects
GCC development, or the next DWARF2 version and various
debugging-related features in the next generation of CPUs affect GDB
development.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Monday, December 21, 2020 at 10:23 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: rms@gnu.org
> Cc: dimech@gmx.com, abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> > From: Richard Stallman <rms@gnu.org>
> > Date: Mon, 21 Dec 2020 00:47:18 -0500
> > Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
> >
> >   > I wonder whether the survey stems from lack of vision of emacs
> >   > admin and developers.  For instance, Gcc has a Development Plan.
> >   > Suggestions for changes to the plan are discussed on the Gcc
> >   > mailing list and can be approved or rejected by the Gcc Steering
> >   > Committee. How about Emacs?
> >
> > GCC has many developers who are paid by various companies.
> > That makes it easier to make plans and actually carry them out.
>
> There's another important difference.  GCC implements programming
> languages defined by evolving standards that are developed by other
> bodies.  The evolution of those language standards largely defines the
> GCC development plans.  Other project, like GDB, Binutils, etc. have
> similar traits: they support hardware and software standards developed
> elsewhere.
>
> But Emacs is its own standard, defined by what we put into it, it
> depends very little on outside developments, and is only tangentially
> affected by those external developments.  So those developments cannot
> determine our plans anywhere near to how the next C++ Standard affects
> GCC development, or the next DWARF2 version and various
> debugging-related features in the next generation of CPUs affect GDB
> development.

You may be correct, but we all have got an indication of what works better.
Emacs could word on setting some standard for the next three years and get
a bit closer to development plans that have proved to be much more sustainable.

But this is just my position.

Re: Emacs Survey: Toolbars

[Jeremy Bryant]

In the spirit of this discussion on the merits and possibility of
planning (or not), there is an interesting quote below.
I found it useful for thinking about the special characteristics of
Emacs, and perhaps others on this list will find it interesting to
consider.




attributed (in the Free as in Freedom book)to RMS from a 1979 AI Lab memo


 EMACS could not have been reached by a process of careful design, because such
 processes arrive only at goals which are visible at the outset, and whose
 desirability is established on the bottom line at the outset. Neither I nor
 anyone else visualized an extensible editor until I had made one, nor
 appreciated its value until he had experienced it. EMACS exists because I felt
 free to make individually useful small improvements on a path whose end was not
 in sight.






Although I couldn't locate the original source of exact quote, there is a longer piece
from the 1979 memo from RMS on the same subject.




Implications for the Process of System Design 

It is generally accepted that when a program is to be written, specifications 
should be designed in advance. If this is not done, the result will be inferior. 
Some people know better than this, but none dare to speak up. 

The writing of EMACS was as far from along these lines as can be imagined. It 
is best thought of as a continuous deformation of TECO into something which, 
for users, has no resemblance to TECO. 

And indeed, there are ways in which EMACS shows the results of not having 
been completely thought out in advance, if only in being based on TECO rather 
than Lisp. (Nevertheless, EMACS has shown itself to be reliable and suitable for 
widespread use). If EMACS hadTbeen specified in advance, it would resemble 
the post-EMACS editors described above. However, the post-EMACS editors 
were specified in advance by EMACS itself, and could not have been written if 
not preceded by EMACS (this is not to say that they have copied slavishly; they 
have continued the process of gradual development). And EMACS could never 
have' been arrived at except in the way it actually was. The chain of necessary 
steps leading to EMACS, starting with the display processor, was simply too long 
for anyone to have imagined the final result before the first step had been taken. 
If we had insisted on moving only toward destinations visible at the beginning, 
we would never have got here from there! 

This is true of all the details of the individual commands as well as of the 
structure of the system. Each command in EMACS behaves as it does as a 
result of experimentation by many different users customizing their editors in 



£ MACS June 22, 1979 



21 



MIT Al Lab 



different ways, in the years when the display processor existed but EMACS had 
not yet been begun. This experimentation was possible only because a 
programmable display editor existed. It would not have been possible to design 
the EMACS standard command set without it. 

Nor can one maintain the position that it was right to create EMACS this way 
because it was research, but ordinary system development is a different matter. 
This is because the difference between the two is also a matter of hindsight. 
EMACS was not the result of an intentional "editor research project" (nor would 
such a project have arrived at EMACS, because research projects aim only at 
goals which are visible at the start). The display processor and command 
dispatcher were seen only as an improvement to TECO; no one could have 
known, when any step was taken, how much farther the path would lead. One 
cannot even identify a "first" step, because the development, until the writing of 
EMACS per se, blends smoothly back into the development' of TECO. 

But why isn't such program of exploration doomed to be sidetracked by a blind 
alley, which nobody will realize due to the lack of a planned goal? 'it is the 
extensibility, and a flexibility of mind, which solves this problem: many alleys 
will be tried at once, and blind alleys can be backed out of with minimal real 
loss. 




Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Mon, 21 Dec 2020 00:47:18 -0500
>> Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
>> 
>>   > I wonder whether the survey stems from lack of vision of emacs
>>   > admin and developers.  For instance, Gcc has a Development Plan.
>>   > Suggestions for changes to the plan are discussed on the Gcc
>>   > mailing list and can be approved or rejected by the Gcc Steering
>>   > Committee. How about Emacs?
>> 
>> GCC has many developers who are paid by various companies.
>> That makes it easier to make plans and actually carry them out.
>
> There's another important difference.  GCC implements programming
> languages defined by evolving standards that are developed by other
> bodies.  The evolution of those language standards largely defines the
> GCC development plans.  Other project, like GDB, Binutils, etc. have
> similar traits: they support hardware and software standards developed
> elsewhere.
>
> But Emacs is its own standard, defined by what we put into it, it
> depends very little on outside developments, and is only tangentially
> affected by those external developments.  So those developments cannot
> determine our plans anywhere near to how the next C++ Standard affects
> GCC development, or the next DWARF2 version and various
> debugging-related features in the next generation of CPUs affect GDB
> development.

Re: Emacs Survey: Toolbars

[Gregory Heytings via Emacs development discussions.]

>
> I've been trying for more than 10 years to urge people to work toward 
> giving Emacs the document capabilities of a word processor, but I have 
> not convinced people to do this work.
>

What do you mean by this?  I'm probably biased, but I don't see what 
important "capability of a word processor" is lacking in Emacs.

Re: Emacs Survey: Toolbars

[Daniel Martín via "Emacs development discussions.]

Gregory Heytings via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

>>
>> I've been trying for more than 10 years to urge people to work
>> toward giving Emacs the document capabilities of a word processor,
>> but I have not convinced people to do this work.
>>
>
> What do you mean by this?  I'm probably biased, but I don't see what
> important "capability of a word processor" is lacking in Emacs.

Something that works like LibreOffice, where you can write a document,
select parts of it, mark them in bold, justify them, etc.  All of that
while you see the results in a WYSIWYG fashion.  The closest thing there
is now is enriched-mode, but that mode does not offer the same level of
features as LibreOffice.

There is more context about this potential new feature in /etc/TODO
under the section "Emacs as a word processor".

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Tue 22 Dec 2020 at 14:22, Daniel Martín via "Emacs development discussions." <emacs-devel@gnu.org> wrote:
> Gregory Heytings via "Emacs development discussions."
> <emacs-devel@gnu.org> writes:
>
>>>
>>> I've been trying for more than 10 years to urge people to work
>>> toward giving Emacs the document capabilities of a word processor,
>>> but I have not convinced people to do this work.
>>>
>>
>> What do you mean by this?  I'm probably biased, but I don't see what
>> important "capability of a word processor" is lacking in Emacs.
>
> Something that works like LibreOffice, where you can write a document,
> select parts of it, mark them in bold, justify them, etc.  All of that
> while you see the results in a WYSIWYG fashion.  The closest thing
> there is now is enriched-mode, but that mode does not offer the same
> level of features as LibreOffice.

I hit a problem with WYSIWYG when trying to implement the WYG part for
emacs-pdf: My console emacs has black background but my paper is white.
Any ideas how to handle this use-case in WYSIWYG editor?

> There is more context about this potential new feature in /etc/TODO
> under the section "Emacs as a word processor".

I do not have /etc/TODO file.  Is there an M-x command to open that TODO
file?

Re: Emacs Survey: Toolbars

[Gregory Heytings via Emacs development discussions.]

>> There is more context about this potential new feature in /etc/TODO 
>> under the section "Emacs as a word processor".
>
> I do not have /etc/TODO file.  Is there an M-x command to open that TODO 
> file?
>

C-h C-t

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Wed 23 Dec 2020 at 15:07, Gregory Heytings <ghe@sdf.org> wrote:
>>> There is more context about this potential new feature in /etc/TODO 
>>> under the section "Emacs as a word processor".
>>
>> I do not have /etc/TODO file.  Is there an M-x command to open that TODO 
>> file?
>>
>
> C-h C-t

great, thanks!

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Wed, 23 Dec 2020 16:04:01 +0100
> 
> > There is more context about this potential new feature in /etc/TODO
> > under the section "Emacs as a word processor".
> 
> I do not have /etc/TODO file.

A typo, sorry: it should be etc/TODO in the Emacs source tree.

Re: Emacs Survey: Toolbars

[Stefan Monnier]

> I hit a problem with WYSIWYG when trying to implement the WYG part for
> emacs-pdf: My console emacs has black background but my paper is white.
> Any ideas how to handle this use-case in WYSIWYG editor?

Easy: use black paper!


        Stefan

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Wed 23 Dec 2020 at 11:39, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> I hit a problem with WYSIWYG when trying to implement the WYG part for
>> emacs-pdf: My console emacs has black background but my paper is white.
>> Any ideas how to handle this use-case in WYSIWYG editor?
>
> Easy: use black paper!

Clever, I haven't thought about that.  Now I only need to find white
toner!

Re: Emacs Survey: Toolbars

[Daniel Martín]

Tomas Hlavaty <tom@logand.com> writes:

>
> I hit a problem with WYSIWYG when trying to implement the WYG part for
> emacs-pdf: My console emacs has black background but my paper is white.
> Any ideas how to handle this use-case in WYSIWYG editor?
>

I'd say that when you render for printing you should always generate a
document with black text over a white background.  Unless the user
explicitly changes the face of parts of the text, in which case you
respect them.  That's not truly WYSIWYG, but seems like a sensible
approach to iterate on.

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Wed 23 Dec 2020 at 20:10, Daniel Martín <mardani29@yahoo.es> wrote:
> Tomas Hlavaty <tom@logand.com> writes:
>> I hit a problem with WYSIWYG when trying to implement the WYG part
>> for emacs-pdf: My console emacs has black background but my paper is
>> white.  Any ideas how to handle this use-case in WYSIWYG editor?
>
> I'd say that when you render for printing you should always generate a
> document with black text over a white background.  Unless the user
> explicitly changes the face of parts of the text, in which case you
> respect them.  That's not truly WYSIWYG, but seems like a sensible
> approach to iterate on.

Yes, that's what I do at the moment and it works fine for monochrome
output.

But if the buffer has colored text and I do not want monochrome output,
how should those colors be chosen?  I do not think that swaping black
and white and keeping all other colors intact would give good results.
And I do not think there is a formula to reverse video colors, or is
there?

Re: Emacs Survey: Toolbars

[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 say that when you render for printing you should always generate a
  > document with black text over a white background.  Unless the user
  > explicitly changes the face of parts of the text, in which case you
  > respect them.  That's not truly WYSIWYG, but seems like a sensible
  > approach to iterate on.

This is equivalent to deciding to consider white-on-black to be a mode
of display rather than a property of the document.  I think it makes
sense.

-- 
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: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Thu 24 Dec 2020 at 23:29, Richard Stallman <rms@gnu.org> wrote:
> This is equivalent to deciding to consider white-on-black to be a mode
> of display rather than a property of the document.  I think it makes
> sense.

It is trivial for monochromatic documents.  The question is: What should
happen if there was another third color in the document?  Should that
third color stay the same on black display and white paper?  Emacs kind
of solves this for display by manually defining faces for each use-case
(black or white background).  But is there a better, automatic way
suitable for printing?  Or maybe the buffer should simply use the same
background as paper?  Is it possible to reverse reverse-video per
buffer?

Re: Emacs Survey: Toolbars

[Stefan Monnier]

> It is trivial for monochromatic documents.

Actually, not even: if you've ever looked at the "negatives" used for
analog black&white photos you'll surely understand that inverse-video
doesn't work so well for images (mostly because it inverses lights and
shadows, thus confusing the semantics).

For a "pure" text or other such circumstances where the colors don't
carry much meaning, it's not too hard to do something like "inverse
video" with an acceptable result, but for photos or comparable kinds of
images, I suspect that it's somewhere between very hard and impossible.


        Stefan

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Fri 25 Dec 2020 at 12:20, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> It is trivial for monochromatic documents.
>
> Actually, not even: if you've ever looked at the "negatives" used for
> analog black&white photos you'll surely understand that inverse-video
> doesn't work so well for images (mostly because it inverses lights and
> shadows, thus confusing the semantics).

Ok, I did not mean gray-scale.  I meant text in black ink on white paper
WYSIWYG edited in Emacs with reverse video colors.  I cannot recall the
proper name for it at the moment but you get the idea.

Now add third color, e.g. to highlight a word in the document.  Simply
swapping background and foreground color can make the highlighted word
badly readable, if the color stays the same.

> For a "pure" text or other such circumstances where the colors don't
> carry much meaning, it's not too hard to do something like "inverse
> video" with an acceptable result, but for photos or comparable kinds
> of images, I suspect that it's somewhere between very hard and
> impossible.

We can leave photos and images out of the question and simply preserve
their colors.

Do you have suggestion for automatically computing "it's not too hard"
color mapping for "inverse video" "pure" text?

Re: Emacs Survey: Toolbars

[Stefan Monnier]

> Do you have suggestion for automatically computing "it's not too hard"
> color mapping for "inverse video" "pure" text?

Convert the color's YUV and invert the Y.


        Stefan

Re: Emacs Survey: Toolbars

[Yuri Khan]

On Sat, 26 Dec 2020 at 01:15, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Do you have suggestion for automatically computing "it's not too hard"
> > color mapping for "inverse video" "pure" text?
>
> Convert the color's YUV and invert the Y.

Possibly better: keep the hue and saturation and recalculate luminance
to preserve the relative contrast to background color.

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Sat 26 Dec 2020 at 01:24, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> On Sat, 26 Dec 2020 at 01:15, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> > Do you have suggestion for automatically computing "it's not too hard"
>> > color mapping for "inverse video" "pure" text?
>>
>> Convert the color's YUV and invert the Y.
>
> Possibly better: keep the hue and saturation and recalculate luminance
> to preserve the relative contrast to background color.

Is there a name for that or more detailed description I could follow?

Re: Emacs Survey: Toolbars

[Yuri Khan]

On Sat, 26 Dec 2020 at 01:29, Tomas Hlavaty <tom@logand.com> wrote:

> >> Convert the color's YUV and invert the Y.
> >
> > Possibly better: keep the hue and saturation and recalculate luminance
> > to preserve the relative contrast to background color.
>
> Is there a name for that or more detailed description I could follow?

Same old: https://www.w3.org/TR/2008/REC-WCAG20-20081211/#contrast-ratiodef

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Sat 26 Dec 2020 at 03:32, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Sat, 26 Dec 2020 at 01:29, Tomas Hlavaty <tom@logand.com> wrote:
>
>> >> Convert the color's YUV and invert the Y.
>> >
>> > Possibly better: keep the hue and saturation and recalculate luminance
>> > to preserve the relative contrast to background color.
>>
>> Is there a name for that or more detailed description I could follow?
>
> Same old: https://www.w3.org/TR/2008/REC-WCAG20-20081211/#contrast-ratiodef

Thanks!  I'll have a look.

RE: Emacs Survey: Toolbars

[Drew Adams]

> > > Do you have suggestion for automatically computing "it's not too hard"
> > > color mapping for "inverse video" "pure" text?
> >
> > Convert the color's YUV and invert the Y.
> 
> Possibly better: keep the hue and saturation and recalculate luminance
> to preserve the relative contrast to background color.

There are lots of ways to "invert" or complement a color.

I just use RGB complementing - good enough for most
purposes for Emacs foregrounds and backgrounds.  Function
`color-complement' in color.el does that.  So does
`hexrgb-complement' in hexrgb.el.

Or I use `hexrgb-hue-complement',
`hexrgb-saturation-complement', or `hexrgb-value-complement'
If I just want to complement one of those components.

RE: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Fri 25 Dec 2020 at 12:25, Drew Adams <drew.adams@oracle.com> wrote:
>> > > Do you have suggestion for automatically computing "it's not too hard"
>> > > color mapping for "inverse video" "pure" text?
>> >
>> > Convert the color's YUV and invert the Y.
>> 
>> Possibly better: keep the hue and saturation and recalculate luminance
>> to preserve the relative contrast to background color.
>
> There are lots of ways to "invert" or complement a color.
>
> I just use RGB complementing - good enough for most
> purposes for Emacs foregrounds and backgrounds.  Function
> `color-complement' in color.el does that.  So does
> `hexrgb-complement' in hexrgb.el.
>
> Or I use `hexrgb-hue-complement',
> `hexrgb-saturation-complement', or `hexrgb-value-complement'
> If I just want to complement one of those components.

Brilliant, it's already in Emacs, thank you!

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Fri 25 Dec 2020 at 13:14, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Do you have suggestion for automatically computing "it's not too
>> hard" color mapping for "inverse video" "pure" text?
>
> Convert the color's YUV and invert the Y.

Thanks for the suggestion!  I'll have a look at that.

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> Date: Tue, 22 Dec 2020 11:03:04 +0000
> Cc: emacs-devel@gnu.org
> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> > I've been trying for more than 10 years to urge people to work toward 
> > giving Emacs the document capabilities of a word processor, but I have 
> > not convinced people to do this work.
> 
> What do you mean by this?  I'm probably biased, but I don't see what 
> important "capability of a word processor" is lacking in Emacs.

The WYSIWYG part is missing.  See the etc/TODO entry about that for
a pointer to a discussion about this.

Re: Emacs Survey: Toolbars

[Arthur Miller]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 22 Dec 2020 11:03:04 +0000
>> Cc: emacs-devel@gnu.org
>> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
>> 
>> > I've been trying for more than 10 years to urge people to work toward 
>> > giving Emacs the document capabilities of a word processor, but I have 
>> > not convinced people to do this work.
>> What do you mean by this?  I'm probably biased, but I don't see what 
>> important "capability of a word processor" is lacking in Emacs.

Personally I think Emacs is half-wysiwyg, or more then half by now. I
think there are almost all tools needed to implement a word processor a
lá Word already in Emacs; I think there is just some minor details
needed; like renderer that can draw efficient representation of a page
below a buffer text (a rectangle) and to tie the text editing stuff to
pixels rather then columns. I was experimenting with modelling a page in
Emacs in context of some other discussion, and that was what I found a
tad bit awkward.

But I am bad at Elisp, and what Emacs already has, so hopefully Eli will
step in and say: "we already have this."

To explain myself:

A word processor usually has some representation of page in paper
format. We can modell a page easily as a region; but it would take
work to implement text processing functions to work with "pages" (insert,
delete etc). It is not hard part, it is just labourous. Problem is when
presenting an empty page to the user to work with in Emacs windows. There is
need to draw some kind of rectangle representing page and user would
type in text above it. Emacs renderer has svg which can render
rectangles fast, but can it render below the buffer text? If it can then
you have everythign needed. I don't know how to do it though.

It is also a bit awkward to work with window-text-pixel-size and 
window-lines-pixel-dimensions because they need a text to being able to
calculate something. When buffer is empty, there is nothing to
calculate. There is need to tell Emacs: "I wish a buffer of this pixel
width and height". In some way. That is what I have seen as a problem,
but it is maybe possible, I am just not aware of funcionality I can use.

I have made a small demo, just roughly modelling a page. To overcome the
need for content in buffer in order to display something, the idea was to
insert "filler-spaces" so I could have something for renderer to
display. I ment to see if I can implement same behaviour as Emacs does
for invisible text: to restrict cursor motion into filler-spaces. But
I never come to that part. The idea was also to model columns, headers,
footers etc just regions in a buffer and to adjust insertion/deletion
routines for "page-mode" so cursor movement, and all the other editing
would look like in a word processor. For example deleteion would delete
a character but insert a filler-character, insertion would insert a
character but delete a filler-character and so on.

I think it is possible, it is just lots of labour I don't have time for
tht myself.

For illustration purpose I have attached the demo I worked on if anyone
would like to look at it, maybe continue or maybe just get an idea how
to implement it more efficiently. Paper size database has to be
evaluated forst, then page.el. It was just a small test I never got back
to, so take it just as a small illustration. Demo is font dependent so
with of the rendered page will depend on what font Emacs uses to
calculate (whatever is default). On my machine it is Anonymous Pro.


[-- Attachment #2: page.el --]
[-- Type: text/plain, Size: 6605 bytes --]

;;; page.el ---                                      -*- lexical-binding: t; -*-

;; Copyright (C) 2020  Arthur Miller

;; Author: Arthur Miller <arthur.miller@live.com>
;; Keywords: 

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:
;;
;; documnet is just a plain buffer with bunch of local variables
;; 
;; page, footer, header and clientarea are ranges between points in the
;; buffer
;; (bopp) (eopp) (bohp) (eohp) (bocp) (eocp) <- similar as (bobp) (eobp)
;;
;; currently footer and header are global for all pages; it would be easy to
;; make them page-unique; just not done currently
;;

;;; Code:
(require 'svg)
(require 'paper-size-iso)

(defface fill-face
  '((t :foreground "white" :background "white" :box "white" :height 100))
  "Default face for document background" :group 'doc)

(defface page-break-face
  '((t :foreground "grey" :background "grey" :box "grey"))
  "Default face for page breaks" :group 'doc)

(defun doc-page-break (doc)
  (let ((svg) (w) (h))
    (with-current-buffer (get-buffer doc)
      (unless pagebreak-svg
        (setq w page-pixel-width
              h (window-font-height nil 'fill-face))
        (message "W: %s H: %s" w h)
        (setq svg (svg-create w h))
        (svg-rectangle svg 0 0 w h :fill "grey")
        (setq pagebreak-svg (svg-image svg :ascent 'center)))
    pagebreak-svg)))

(defun doc-new (&optional title)
  (interactive)
  
  (unless title
    (setq title "New Document"))

  (let ((doc (generate-new-buffer title)))

    (with-current-buffer (get-buffer-create doc)

      (setq screen-res 96
            print-res 300
            format 'A4
            orientation 'portrait
            pages 1
            current-page 0
            page-rows 0
            page-cols 0
            header nil
            footer nil
            document (current-buffer)
            pagebreak-svg nil
            real-pixel-width 0
            page-pixel-width 0
            page-pixel-height 0)

      (make-local-variable 'document)
      (make-local-variable 'title)
      (make-local-variable 'screen-res)
      (make-local-variable 'print-res)
      (make-local-variable 'format)
      (make-local-variable 'orientation)
      (make-local-variable 'pages)
      (make-local-variable 'current-page)
      (make-local-variable 'page-pixel-width)
      (make-local-variable 'page-pixel-height)
      (make-local-variable 'page-rows)
      (make-local-variable 'page-cols)
      (make-local-variable 'real-pixel-width)
      (make-local-variable 'header)
      (make-local-variable 'footer)
      (make-local-variable 'pagebreak-svg)
      
      (let ((dims (paper-size-iso-in-to-pixels format screen-res)))
        (setq page-pixel-width (car dims))
        (setq page-pixel-height (cdr dims))))

      (switch-to-buffer doc)
      (doc-insert-page doc (point-min))
  document))

(defun doc-append-page ()
  "Append a new page at the end"
  (interactive)
  (with-current-buffer (buffer-name)
  (doc-insert-page (buffer-name) (point-max))))

(defun doc-insert-pagebreak (buffer point)
  (with-current-buffer buffer
    (goto-char point)
    (setq real-pixel-width
	  (car (window-text-pixel-size
                nil (beginning-of-line) (end-of-line))))
    (insert ?\n)
    ;; (insert ?\^L)
    ;; (set-text-properties (line-beginning-position) (line-end-position)
    ;;                      `(face nil display ,(doc-page-break buffer)))
    ;; (newline)
    ))

(defun doc-insert-footer (buffer point)
  (save-excursion
    (with-current-buffer buffer
      (goto-char point)
      (insert (buffer-substring (car footer) (cdr footer))))))

(defun doc-insert-header (buffer point)
  (save-excursion
    (with-current-buffer buffer
      (goto-char point)
      (insert (buffer-substring (car header) (cdr header))))))

(defun doc-insert-page (buffer point)
  "Insert page at point."
  (with-current-buffer buffer
    (hl-line-mode -1)
    (auto-fill-mode -1)
    (goto-char point)
    ;; Emacs needs a live window to calculate pixel sizes
    ;; so we have to calculate stuff when first page is shown
    (if (= 0 current-page)
        (let* ((w 0) (h 0) (space-width) (space-height) (d)
              (font-width (window-font-width nil 'fill-face))
              (font-height (window-font-height nil 'fill-face)))

          (insert ?\s)
          (set-text-properties point (point-max) '(face fill-face))
          (setq space-width (car (window-text-pixel-size
                                  nil (beginning-of-line) (end-of-line))))
          (setq space-height (cdr (window-text-pixel-size
                                  nil (beginning-of-line) (end-of-line))))
          (setq cols (truncate (fround (/ page-pixel-width font-width))))
          (setq rows (truncate (fround (/ page-pixel-height font-height))))
          (setq cols (+ cols (truncate (/ 158 font-width)))) ;; some nasty magick here
          (delete-backward-char 1)

          (setq page-cols cols page-rows rows)
          (while (< h rows)
            (self-insert-command cols ?\s)
            (setq h (+ h 1))
            (newline)))
      (progn ;; we already have page dimensions
        (doc-insert-pagebreak buffer (point))
        (setq point (point))
        (dotimes (i page-rows)
          (self-insert-command page-cols ?\s)
          (newline))))
    (set-text-properties point (point-max) '(face fill-face))
    (setq current-page (+ current-page 1))
    ;;(setq pages (append pages (list point (- (point-max) 1))))
    ))

(defun buffer-document (&optional buffer)
  (unless buffer
    (setq buffer (buffer-name)))
  (with-current-buffer (get-buffer buffer)
    document))

(defun doc-set-footer (begin end)
  "Set current region as footer."
  (interactive "r")
  (with-current-buffer (buffer-document)
    (setq footer (cons begin end))))

(defun doc-set-header (begin end)
  "Set current region as header."
  (interactive "r")
  (with-current-buffer (buffer-document)
    (setq header (cons begin end))))

(provide 'page)
;;; page.el ends here

[-- Attachment #3: paper-size-iso.el --]
[-- Type: text/plain, Size: 7136 bytes --]

;;; paper-size-iso-us.el ---                               -*- lexical-binding: t; -*-

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:
;;
;;; References:
;;  http://www.printernational.org/iso-paper-sizes.php
;;  https://papersizes.io/a/
;;  https://en.wikipedia.org/wiki/Pixel_density
;;  https://blog.gimm.io/difference-between-pixel-px-and-point-pt-font-sizes-in-email-signatures/

;;  https://honeywellaidc.force.com/supportppr/s/article/How-to-convert-inches-in-dots
;;  https://www.shutterstock.com/blog/inches-to-pixels-resize-image-quality
;;  https://www.shutterstock.com/blog/ppi-vs-dpi-resolution-guidex
;;  https://www.pixelsconverter.com/

(defvar paper-size-iso '(;; Size      Width x Height(mm) Width x Height(in) 
                         (4A0         . [1682  2378      66.2    93.6 ])
                         (2A0         . [1189  1682      46.8    66.2 ])
                         (A0          . [841   1189      33.1    46.8 ])
                         (A1          . [594   841       23.4    33.1 ])
                         (A2          . [420   594       16.5    23.4 ])
                         (A3          . [297   420       11.7    16.5 ])
                         (A4          . [210   297       8.3     11.7 ])
                         (A5          . [148   210       5.8     8.3  ])
                         (A6          . [105   148       4.1     5.8  ])
                         (A7          . [74    105       2.9     4.1  ])
                         (A8          . [52    74        2.0     2.9  ])
                         (A9          . [37    52        1.5     2.0  ])
                         (A10         . [26    37        1.0     1.5  ])
                         (A11         .	[18    26  	 0.7     1    ])
                         (A12         .	[13    18  	 0.5     0.7  ])
                         (A13         .	[9     13  	 0.4     0.5  ])
                         (2A0         .	[1189  1682  	 46.8    66.2 ])
                         (4A0         .	[1682  2378  	 66.2    93.6 ])
                         (A0+         .	[914   1292  	 36      50.9 ])
                         (A1+         .	[609   914  	 24      36   ])
                         (A3+         .	[329   483  	 13      19   ])
                         (A2-extra    . [445   619       17.51   24.3 ])
                         (A3-extra    . [322   445       12.67   17.51])
                         (A3-Super    . [305   508       12      20   ])
                         (Super-A3    . [305   487       12      19.17])
                         (A4-extra    . [235   322       9.25    12.67])
                         (A4-Super    . [229   322       9.25    12.67])
                         (Super-A4    . [227   356       8.93    14.01])
                         (A4-Long     . [210   348       8.26    13.7 ])
                         (A5-extra    . [173   235       8.26    9.25 ])
                         (SO-B5-extra . [202   276       7.95    10.86])
                         (B0          . [1000  1414      33.37   55.67])
                         (B1          . [707   1000      27.84   39.37])
                         (B2          . [500   707       19.69   27.84])
                         (B3          . [353   500       13.9    19.69])
                         (B4          . [250   352       9.84    13.9 ])
                         (B5          . [176   250       6.93    9.84 ])
                         (B6          . [125   176       4.92    6.93 ])
                         (B7          . [88    125       3.47    4.92 ])
                         (B8          . [62    88        2.44    3.47 ])
                         (B9          . [44    62        1.73    2.44 ])
                         (B10         .	[31    44        1.22    1.73 ])
                         (B11         .	[22    31 	 0.9     1.2  ])
                         (B12         .	[15    22 	 0.6     0.9  ])
                         (B13         .	[11    15 	 0.4     0.6  ])
                         (B0+         .	[1118  1580 	 44      62.2 ])
                         (B1+         .	[720   1020 	 28.3    40.2 ])
                         (B2+         .	[520   720 	 20.5    28.3 ])
                         (C0          . [917   1297  	 36.12   51.6 ])
                         (C1          . [648   917  	 25.50   36.12])
                         (C2          . [458   648  	 18      25.50])
                         (C3          . [324   458  	 12.75   18   ])
                         (C4          . [229   324  	 9       12.75])
                         (C5          . [162   229  	 6.38    9    ])
                         (C6          . [114   162  	 4.5     6.38 ])
                         (C7          . [81    114  	 3.19    4.5  ])
                         (C8          .	[57    81 	 2.2     3.2  ])
                         (C9          .	[40    57 	 1.6     2.2  ])
                         (C10         .	[28    40 	 1.1     1.6  ])
                         (C6/C5       . [229   114 	 9       4.5  ])
                         (C7/C6       . [81    162  	 3.19    6.38 ])
                         (DL          . [110   220  	 4.32    8.69 ])
                         (E4 	      . [400   280 	 15.7    11   ])
                         ))

(defun paper-size-dimensions (format)
  "Return dimensions in inch for given FORMAT as specified in ISO standard for
  paper sizes."
  (cdr (assoc format paper-size-iso)))

(defun paper-size-iso-mm-to-pixels (format resolution)
   (let* ((dims (paper-size-dimensions format))
          (width (aref dims 0))
          (height (aref dims 1)))
    (paper-size-pixels width height 'mm resolution)))

(defun paper-size-iso-in-to-pixels (format resolution)
  (let* ((dims (paper-size-dimensions format))
         (width (aref dims 2))
         (height (aref dims 3)))
    (paper-size-pixels width height 'in resolution)))

(defun paper-size-pixels (width height unit resolution)
  "Return size in pixels from width and height. 
UNIT is unit of dimension
  measurement, either millimmeter or inches. For millimeter pass 'mm, for
  inches pass 'in.
Resolution is number of either pixels per inches for the screen, or dots per
  inches for printers.
Resolution-unit is either 'ppi for the screen or 'dpi for printers"
  (when (equal unit 'mm)
    (setq width (/ width 25.4))
    (setq height (/ height 25.4)))
  (setq width (fround (* width resolution)))
  (setq height (fround (* height resolution)))
  (cons (ftruncate width) (ftruncate height)))

(provide 'paper-size-iso)

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: Gregory Heytings <ghe@sdf.org>,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 22 Dec 2020 18:52:48 +0100
> 
> Personally I think Emacs is half-wysiwyg, or more then half by now. I
> think there are almost all tools needed to implement a word processor a
> lá Word already in Emacs; I think there is just some minor details
> needed; like renderer that can draw efficient representation of a page
> below a buffer text (a rectangle) and to tie the text editing stuff to
> pixels rather then columns. I was experimenting with modelling a page in
> Emacs in context of some other discussion, and that was what I found a
> tad bit awkward.
> 
> But I am bad at Elisp, and what Emacs already has, so hopefully Eli will
> step in and say: "we already have this."

I think most of the necessary infrastructure exists indeed.  However,
building a WYSIWYG word processor on top of that is not a trivial job,
although probably not rocket science, either.  I'd start from
enriched.el and took it from there.

Re: Emacs Survey: Toolbars

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Gregory Heytings <ghe@sdf.org>,  rms@gnu.org,  emacs-devel@gnu.org
>> Date: Tue, 22 Dec 2020 18:52:48 +0100
>> 
>> Personally I think Emacs is half-wysiwyg, or more then half by now. I
>> think there are almost all tools needed to implement a word processor a
>> lá Word already in Emacs; I think there is just some minor details
>> needed; like renderer that can draw efficient representation of a page
>> below a buffer text (a rectangle) and to tie the text editing stuff to
>> pixels rather then columns. I was experimenting with modelling a page in
>> Emacs in context of some other discussion, and that was what I found a
>> tad bit awkward.
>> 
>> But I am bad at Elisp, and what Emacs already has, so hopefully Eli will
>> step in and say: "we already have this."
>
> I think most of the necessary infrastructure exists indeed.  However,
> building a WYSIWYG word processor on top of that is not a trivial job,
> although probably not rocket science, either.  I'd start from
> enriched.el and took it from there.
Yeah, I know; that is why I said it is not hard, but labourous. Yes I
was thinking of enriched mode, and some parts of org.

Rougier has made a very nice demo with svg-toolbars; those things could
be put together to create a kind of wysyvig where people can mark text,
set it to italics/bold etc. Justifying text could be done too. But
without being able to render a page representation in a buffer, it
wouldn't be feel of a word processor.

Maybe the feel is not that important; maybe it is enough to just render two
lines where page width and page height are, so user can adjust text
manually when he/she sees it go out of the "page range".

Printed preview could be achieved with svg renderer just rendering
buffer into an image of given page width and height. Would need to take
printer characteristics into account, but some basic print preview, not
pixel perfect could be achieved relatively easy.

Re: Emacs Survey: Toolbars

[Jean Louis]

Maybe you wanted this:

as white-white does not show anything.

(defface fill-face
  '((t :foreground "black" :background "white" :box "white" :height 100))
  "Default face for document background" :group 'doc)

Re: Emacs Survey: Toolbars

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> Maybe you wanted this:
>
> as white-white does not show anything.

?

It was just a test to modell a page .... it's not something you can
use. You can just create a document and insert a page. Nothing else is
implemented. 

But if you are interested to work on it, enjoy it :-).

Re: Emacs Survey: Toolbars

[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 is need to tell Emacs: "I wish a buffer of this pixel
  > width and height".

LibreOffice doesn't ask that question, and it lets you start editing
text and knows what size to use by default for the page.
I suggest looking at what it does.

One interesting question is how to make text flow between pages.  In
Emacs, a page boundary is a ^L character (formfeed).  To make text
flow between pages would require deleting and inserting ^L characters
as needed.  Is that workable?

(I remember when ^L made the line printer skip to the next page.)

  > For example deleteion would delete
  > a character but insert a filler-character, insertion would insert a
  > character but delete a filler-character and so on.

I don't follow that.  Could you give a concrete example and say
what these fillers would do, what benefit would result.
I think they would be a pain in the neck
for all the editing commands.

-- 
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: Emacs Survey: Toolbars

[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. ]]]
>
>   >  There is need to tell Emacs: "I wish a buffer of this pixel
>   > width and height".
>
> LibreOffice doesn't ask that question, and it lets you start editing
> text and knows what size to use by default for the page.
Somewhere under the hood in it's source code it does. :-)

I don't think you have understood what I ment there. Maybe I was too
flumsy when writing.

What I ment is that somewhere in the application code there have to be a
database of papersizes, so that application can draw that representation
of a page on the screen such as they do in Writer for example and how
wide lines will be so it can break lines properly, where user text would
start on those line, on the page, when to break to next page etc.

One annoyance is also renderer which in Emacs can't draw an "empty
buffer". Libre Office draws a white rectangle and some lines
around. Emacs can't do that since we can't draw things in layers, at
least what I am aware of (Mr. Eli? ).

Maybe that itself is not that desirable, and could be a "nice ot have "
feature but which can easily be lived without. As a poor man version,
one can just draw lines with unicode chars '|' where say width of page
ends for visual representation and simply insert ^L styled vid svg image
where page ends.

> One interesting question is how to make text flow between pages.  In
> Emacs, a page boundary is a ^L character (formfeed).  To make text
> flow between pages would require deleting and inserting ^L characters
> as needed.  Is that workable?
I think that would be conceptually trivial, but labourous as now, that
is what I tried to say in mail with demo I sent. I had idea the idea to
do in that demo, but I never got back to work more on it. 

Insertion routine would need to know where pages starts and ends. I
think a page can be modelled just as a range between two points (a
region). There are more details of course; printer margins have to be
taken account, headers, footers, client area and what not.

But roughly insertion, deletion and other text routines whichever they
are, would need to check if text in a page has reached to certain point
and if it is to insert ^L and reflow the page(s) as needed.


> (I remember when ^L made the line printer skip to the next page.)
>
>   > For example deleteion would delete
>   > a character but insert a filler-character, insertion would insert a
>   > character but delete a filler-character and so on.
>
> I don't follow that.  Could you give a concrete example and say
> what these fillers would do, what benefit would result.
> I think they would be a pain in the neck
> for all the editing commands.
Yes, they would be pain, but all editing commands would have to be
changed anyway. There would be some document mode or wysiwyg mode or
whatever which would have to either overwrite or advise insertion,
deletion, etc.

Those filler spaces was my compensation for how Emacs buffer and renderer
works.

I had an idea to emulate visually a page as in a wyswyg editor. Emacs
can't render an empty buffer of certain size, not what I know. Maybe it
is possible to do something with child frames, or fringes or some other
trick, I don't know. But it was a compensation, I calculated a number of
columns with default font to fill a certain width in pixels. It is a
flawed approach, but it was just an experiment. So I insert just white
space characters which I call "filler space".

The idea was also to use them conceptually like spacers so I can tell
the insertion routine to really start from column X and not from first
char in line, and to break at column Y and not the last column.

I see page as consising of header, client and footer areas which are all
just ranges, so it really is just checking some integers; not very
hard. I also see those areas start at some margins (printer margins),
since printers can't print directly from the edge of the paper.

Also insertion deletion would have to take into account they work in a
page, header etc, so when character is inserted somewhere in a page, one
would have to delete a character at the end of page or rather client
area. But that would all be just a hierarchical delegation when it comes
to implementation.

Also since we are inserting in a buffer, inserting a char in first page
could potentially move all chars in a 100 pages long book. That is
probably now what we want. We just want to move text on that page. Filler
space was ment to be used there as spacer too. Insertion would delete a
space at the end of line or client area to make room for user character
so not entire Emacs buffer is moved around.

I also wanted to see if I can give them similar property as invisible
text in Emacs has; I wanted to restrict cursor to move into filler
space, but I never got to that part, so I don't know if it is possible.

It was just an experiment. If I remember, in demo I posted, one can
break page at arbitrary point and insert new ones. But what I noticed is
that it was very slow after few pages were added. Also there are other
problems, for example most important is how to calculate width of
columns to start with? Take a space character and see how many fit into
given pixel width? Or some average size? I took space for the
experiment, but it is not acceptable approach in general.

Maybe it is more effective to not visually model a page, but to just
render a line where line ends so user can see text has got out of page
width and can reflow things themselves. It could be cheap start at least
and probably not so hard to implement.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Wednesday, December 23, 2020 at 4:51 PM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Richard Stallman" <rms@gnu.org>
> Cc: ghe@sdf.org, eliz@gnu.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> 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. ]]]
> >
> >   >  There is need to tell Emacs: "I wish a buffer of this pixel
> >   > width and height".
> >
> > LibreOffice doesn't ask that question, and it lets you start editing
> > text and knows what size to use by default for the page.
> Somewhere under the hood in it's source code it does. :-)
>
> I don't think you have understood what I ment there. Maybe I was too
> flumsy when writing.
>
> What I ment is that somewhere in the application code there have to be a
> database of papersizes, so that application can draw that representation
> of a page on the screen such as they do in Writer for example and how
> wide lines will be so it can break lines properly, where user text would
> start on those line, on the page, when to break to next page etc.

Texinfo does things that way.

> One annoyance is also renderer which in Emacs can't draw an "empty
> buffer". Libre Office draws a white rectangle and some lines
> around. Emacs can't do that since we can't draw things in layers, at
> least what I am aware of (Mr. Eli? ).
>
> Maybe that itself is not that desirable, and could be a "nice ot have "
> feature but which can easily be lived without. As a poor man version,
> one can just draw lines with unicode chars '|' where say width of page
> ends for visual representation and simply insert ^L styled vid svg image
> where page ends.
>
> > One interesting question is how to make text flow between pages.  In
> > Emacs, a page boundary is a ^L character (formfeed).  To make text
> > flow between pages would require deleting and inserting ^L characters
> > as needed.  Is that workable?
> I think that would be conceptually trivial, but labourous as now, that
> is what I tried to say in mail with demo I sent. I had idea the idea to
> do in that demo, but I never got back to work more on it.
>
> Insertion routine would need to know where pages starts and ends. I
> think a page can be modelled just as a range between two points (a
> region). There are more details of course; printer margins have to be
> taken account, headers, footers, client area and what not.
>
> But roughly insertion, deletion and other text routines whichever they
> are, would need to check if text in a page has reached to certain point
> and if it is to insert ^L and reflow the page(s) as needed.
>
>
> > (I remember when ^L made the line printer skip to the next page.)
> >
> >   > For example deleteion would delete
> >   > a character but insert a filler-character, insertion would insert a
> >   > character but delete a filler-character and so on.
> >
> > I don't follow that.  Could you give a concrete example and say
> > what these fillers would do, what benefit would result.
> > I think they would be a pain in the neck
> > for all the editing commands.
> Yes, they would be pain, but all editing commands would have to be
> changed anyway. There would be some document mode or wysiwyg mode or
> whatever which would have to either overwrite or advise insertion,
> deletion, etc.
>
> Those filler spaces was my compensation for how Emacs buffer and renderer
> works.
>
> I had an idea to emulate visually a page as in a wyswyg editor. Emacs
> can't render an empty buffer of certain size, not what I know. Maybe it
> is possible to do something with child frames, or fringes or some other
> trick, I don't know. But it was a compensation, I calculated a number of
> columns with default font to fill a certain width in pixels. It is a
> flawed approach, but it was just an experiment. So I insert just white
> space characters which I call "filler space".
>
> The idea was also to use them conceptually like spacers so I can tell
> the insertion routine to really start from column X and not from first
> char in line, and to break at column Y and not the last column.
>
> I see page as consising of header, client and footer areas which are all
> just ranges, so it really is just checking some integers; not very
> hard. I also see those areas start at some margins (printer margins),
> since printers can't print directly from the edge of the paper.
>
> Also insertion deletion would have to take into account they work in a
> page, header etc, so when character is inserted somewhere in a page, one
> would have to delete a character at the end of page or rather client
> area. But that would all be just a hierarchical delegation when it comes
> to implementation.
>
> Also since we are inserting in a buffer, inserting a char in first page
> could potentially move all chars in a 100 pages long book. That is
> probably now what we want. We just want to move text on that page. Filler
> space was ment to be used there as spacer too. Insertion would delete a
> space at the end of line or client area to make room for user character
> so not entire Emacs buffer is moved around.
>
> I also wanted to see if I can give them similar property as invisible
> text in Emacs has; I wanted to restrict cursor to move into filler
> space, but I never got to that part, so I don't know if it is possible.
>
> It was just an experiment. If I remember, in demo I posted, one can
> break page at arbitrary point and insert new ones. But what I noticed is
> that it was very slow after few pages were added. Also there are other
> problems, for example most important is how to calculate width of
> columns to start with? Take a space character and see how many fit into
> given pixel width? Or some average size? I took space for the
> experiment, but it is not acceptable approach in general.
>
> Maybe it is more effective to not visually model a page, but to just
> render a line where line ends so user can see text has got out of page
> width and can reflow things themselves. It could be cheap start at least
> and probably not so hard to implement.
>
>

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Wed 23 Dec 2020 at 12:21, Arthur Miller <arthur.miller@live.com> wrote:
> database of papersizes

Emacs already has that.

This is what I use in emacs-pdf:

(defun pdf-page-dimensions ()
  "Return values of page width and height depending on
ps-paper-type and ps-landscape-mode."
  (let ((x (cdr (assq ps-paper-type ps-page-dimensions-database))))
    (if ps-landscape-mode
        (values (cadr x) (car x))
      (values (car x) (cadr x)))))

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: eliz@gnu.org,  ghe@sdf.org,  emacs-devel@gnu.org
> Date: Wed, 23 Dec 2020 12:21:12 +0100
> 
> One annoyance is also renderer which in Emacs can't draw an "empty
> buffer". Libre Office draws a white rectangle and some lines
> around. Emacs can't do that since we can't draw things in layers, at
> least what I am aware of (Mr. Eli? ).

I don't think I understand what you are saying, because you didn't
elaborate about the "white rectangle and some lines around" drawn by
LibreOffice.  Emacs _is_ capable of displaying an empty buffer, you
can easily see that for you self if you do "C-x b foobar RET".  And we
also have some decorations around the window and the frame, regardless
of whether or not there's text displayed there.

So I think the important question here is: what would we like/need to
display "around" an empty text area?  Armed with that knowledge, we
could discuss how to do that in Emacs (if we decide it's important
enough).

I also think that it is not wise to talk about page decorations before
we actually have a WYSIWYG editor that can display formatted text.
The decorations are secondary features, IMO, the perceived difficulty
in providing them shouldn't stop us from implementing "the meat" of
any word processor.

Re: Emacs Survey: Toolbars

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-12-23 18:57]:
> I also think that it is not wise to talk about page decorations before
> we actually have a WYSIWYG editor that can display formatted text.
> The decorations are secondary features, IMO, the perceived difficulty
> in providing them shouldn't stop us from implementing "the meat" of
> any word processor.

Exactly, the next 2021 year is good one to get some WYSIWYG features
and word processing in Emacs.

Sv: Emacs Survey: Toolbars

[arthur miller]

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

You probably don't, because I certainly wasn't talking about decorations 🙂.  Why would I do talk about decorations?

> Emacs _is_ capable of displaying an empty buffer, you
> can easily see that for you self if you do "C-x b foobar RET".

Yes, an Emacs buffers of course. I have seen it, 20 years now 🙂.

I don't know if I expressed myself badly, I don't remember what I said and I am often too fast to type; but I
was talking about visual feedback to user: so called what-you-see part
in wysiwyg. When I say white rectangle, or at least some lines or some notification
to user when he/she is typing outside buffer, it is not about "decorations" it is
about visual feedback what is going on. Otherwise it is not much of a wysiwyg, isn't it?

> So I think the important question here is: what would we like/need to
> display "around" an empty text area?  Armed with that knowledge, we
> could discuss how to do that in Emacs (if we decide it's important
> enough).

Yes, I agree; and sure that feedback can be minimal, for example, Emacs could simply prevent
user from typing after certain width, and insert just ^L after certain height, but some feedback
is needed. Emacs could just draw a line on the right edge with pipe characters as I mentioned
before; but having a nice background representation of a page in form of a rectangle and some
support lines to show where margins are would be much nicer and give more of a wysiwyg feel.

> And we also have some decorations around the window and the frame, regardless
> of whether or not there's text displayed there.

Yes I know of course, but these are around frames and windows. Imagine an A4 page. It
would be nice if user have some visual cue where edges of the page start and end and so on.
Windows and frames can be resized, and they are buffer specific. A document can have many
pages. Users might also wish to resize window to show just part of the page maybe? I am not
sure how would you tie a window to page, but I am not so introduced to Emacs internals either.

I had thoughts to use a child frame to display a page and show just a part of a buffer in it, or to
use a buffer per page, but I don't think it is good idea. Maybe you see some other possibility.

> I also think that it is not wise to talk about page decorations before
> we actually have a WYSIWYG editor that can display formatted text.

You can already display formatted text. You have implemented it! Emacs draws italics, and bold, and superscripts,
different fonts and what not. It just has to be connected to a button! N. Rougier made awesome little svg library for
toolbars and now he posted little svg-icon library to download icons. It is justto create some nice svg buttons
and toolbars and connect it to those functions for text formatting.

Of course decorations are secondary, but visual feedback in a wysiwyg tool shouldn't be secondary; it is
not about decorations, it is about giving user feel and visual help to manipulate objects on the screen.

At least that was my thought 🙂.

Merry Christmass to all! <3
________________________________
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 23 december 2020 16:56
Till: Arthur Miller <arthur.miller@live.com>
Kopia: rms@gnu.org <rms@gnu.org>; ghe@sdf.org <ghe@sdf.org>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Emacs Survey: Toolbars

> From: Arthur Miller <arthur.miller@live.com>
> Cc: eliz@gnu.org,  ghe@sdf.org,  emacs-devel@gnu.org
> Date: Wed, 23 Dec 2020 12:21:12 +0100
>
> One annoyance is also renderer which in Emacs can't draw an "empty
> buffer". Libre Office draws a white rectangle and some lines
> around. Emacs can't do that since we can't draw things in layers, at
> least what I am aware of (Mr. Eli? ).

I don't think I understand what you are saying, because you didn't
elaborate about the "white rectangle and some lines around" drawn by
LibreOffice.  Emacs _is_ capable of displaying an empty buffer, you
can easily see that for you self if you do "C-x b foobar RET".  And we
also have some decorations around the window and the frame, regardless
of whether or not there's text displayed there.

So I think the important question here is: what would we like/need to
display "around" an empty text area?  Armed with that knowledge, we
could discuss how to do that in Emacs (if we decide it's important
enough).

I also think that it is not wise to talk about page decorations before
we actually have a WYSIWYG editor that can display formatted text.
The decorations are secondary features, IMO, the perceived difficulty
in providing them shouldn't stop us from implementing "the meat" of
any word processor.

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

Re: Sv: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> CC: "rms@gnu.org" <rms@gnu.org>, "ghe@sdf.org" <ghe@sdf.org>,
> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 24 Dec 2020 04:40:23 +0000
> 
> > I also think that it is not wise to talk about page decorations before
> > we actually have a WYSIWYG editor that can display formatted text.
> 
> You can already display formatted text. You have implemented it! Emacs draws italics, and bold, and
> superscripts,
> different fonts and what not. It just has to be connected to a button! N. Rougier made awesome little svg
> library for
> toolbars and now he posted little svg-icon library to download icons. It is justto create some nice svg buttons
> and toolbars and connect it to those functions for text formatting.

Those things we "just" have to do, must be done, otherwise we cannot
claim to be anywhere near a word processor, because it is unimaginable
in a word processor to apply faces via Edit->Text Properties, let
alone via lower-level commands.

And the next thing to do is the ability to save all that face
information to a disk file, so that the next time you visit the file
you see the same faces.  Enriched mode does that, but it needs more
love.

Next after that is pixel-level indentation and filling/justification,
so that we could use variable-pitch fonts.

Next are the printing facilities, where I hope we will once and for
all solve the problem of printing non-ASCII, non-Latin-1 characters.

When we have done all that, we will have a significant portion of a
word processor, IMO.

Re: Emacs Survey: Toolbars

[Tomas Hlavaty]

On Tue 22 Dec 2020 at 23:21, Richard Stallman <rms@gnu.org> wrote:
> One interesting question is how to make text flow between pages.  In
> Emacs, a page boundary is a ^L character (formfeed).  To make text
> flow between pages would require deleting and inserting ^L characters
> as needed.  Is that workable?
>
> (I remember when ^L made the line printer skip to the next page.)

In emacs-pdf, I respect ^L and start a new page.  Additionally, a new
pdf page is automatically started when the page gets full (but this is
not indicated in the original text buffer).  It could probably be
feasible to indicate the additional computed page break in the original
text buffer but then there should be a concept of user-entered page
break (e.g. ^L) and computed page break (how to indicated that?).

Another problem with pages is that it requires user configuration (like
emacs has for postcript printing which could be reused) and whole
complexity of fonts and layout.  So far emacs-pdf handles ascii
monospace monochrome buffers only thus in a sense it is already WYSIWYG.
I get the same thing on the paper as on the screen (minus headers and
footers).

Should headers and footers be also displayed in the original text
buffer?  Should they be editable?  How should it be handled at the low
level, e.g. as a text property?

Another problem is inserting computed values, e.g. current page number
or total number of pages, which is often used in headers and footers.
This means that the whole rendering becomes a fixed-point computation.
In emacs-pdf, I simply process the whole document twice and assume that
the layout would not change further anymore but that is not a general
solution.

Re: Emacs Survey: Toolbars

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-12-22 20:53]:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Tue, 22 Dec 2020 11:03:04 +0000
> >> Cc: emacs-devel@gnu.org
> >> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> >> 
> >> > I've been trying for more than 10 years to urge people to work toward 
> >> > giving Emacs the document capabilities of a word processor, but I have 
> >> > not convinced people to do this work.
> >> What do you mean by this?  I'm probably biased, but I don't see what 
> >> important "capability of a word processor" is lacking in Emacs.
> 
> Personally I think Emacs is half-wysiwyg, or more then half by now.

I can print into PDF or Postscript and will get a different font then
on the screen. Good for me as I am fine with my printing, yet it does
not reach What You See Is What You Get paradigm. If I would record
screenshot, that would be only case to get what I see.

In the Org mode there is Title and Author keywords, so that is far far
from getting what you are seeing.

If we reach what LyX document processor has reached, the paradigm of
WYSIWYM or What You See Is What You Mean that would be already
enough. That could be reached already now if basic fonts such as
Courier, Roman, Sans Serif, can be mixed and they can
be.

See:
https://en.wikipedia.org/wiki/WYSIWYM

Re: Emacs Survey: Toolbars

[Christopher Dimech]

I have used Lyx , but turned to Emacs as it was better to configure.
The WYSIWYG is good though.

> Sent: Wednesday, December 23, 2020 at 6:15 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Arthur Miller" <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> * Arthur Miller <arthur.miller@live.com> [2020-12-22 20:53]:
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > >> Date: Tue, 22 Dec 2020 11:03:04 +0000
> > >> Cc: emacs-devel@gnu.org
> > >> From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>
> > >>
> > >> > I've been trying for more than 10 years to urge people to work toward
> > >> > giving Emacs the document capabilities of a word processor, but I have
> > >> > not convinced people to do this work.
> > >> What do you mean by this?  I'm probably biased, but I don't see what
> > >> important "capability of a word processor" is lacking in Emacs.
> >
> > Personally I think Emacs is half-wysiwyg, or more then half by now.
>
> I can print into PDF or Postscript and will get a different font then
> on the screen. Good for me as I am fine with my printing, yet it does
> not reach What You See Is What You Get paradigm. If I would record
> screenshot, that would be only case to get what I see.
>
> In the Org mode there is Title and Author keywords, so that is far far
> from getting what you are seeing.
>
> If we reach what LyX document processor has reached, the paradigm of
> WYSIWYM or What You See Is What You Mean that would be already
> enough. That could be reached already now if basic fonts such as
> Courier, Roman, Sans Serif, can be mixed and they can
> be.
>
> See:
> https://en.wikipedia.org/wiki/WYSIWYM
>
>
>
>
>
>

Re: Emacs Survey: Toolbars

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-12-23 16:10]:
> I have used Lyx , but turned to Emacs as it was better to configure.
> The WYSIWYG is good though.

Actually LyX is using WYSIWYM paradigm, like What You See Is What You
Mean. If I don't want to think much about formatting within Emacs, I
will use LyX, it offers me quicker LaTeX and other similar TeX based
templates.

After a while of work, after months or years, then I have those
LaTeX templates anyway on computer, so what I do is just open one
LaTeX template, rename it for new purpose, modify the text and insert
new text and voilà.

My largest problem with LyX is that I have to use X org based keyboard
bindings to switch between languages as I often use 2-3
languages. Switching the input method in Emacs is so much more
easier with C-\ and setting it up with C-RET-\

I may use Arabic keyboard with some weird hard to find English layout,
Emacs helps there. German input method on US layout, Emacs helps, and
so on.

I just wish other systems would have input methods that well defined.

I like vim and vi editors as well, but input methods are missing or I
do not know how to set it, so I have to use xmodmap.

Re: Emacs Survey: Toolbars

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

  > Actually LyX is using WYSIWYM paradigm, like What You See Is What You
  > Mean.

That is fine for some jobs, but not adequate for writing text to fit
in one or two sides of a sheet of paper.  For that I have to use
LibreOffice -- and I always wish it had the Emacs editing facilities.

-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

I understand what you mean.  Whan I want to print something quick,
I also have to turn to LibreOffice.  I wrangled that a new major mode
could suffice, but I am not an knowledgeable enough to be sure.


> Sent: Thursday, December 24, 2020 at 11:20 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Jean Louis" <bugs@gnu.support>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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. ]]]
>
>   > Actually LyX is using WYSIWYM paradigm, like What You See Is What You
>   > Mean.
>
> That is fine for some jobs, but not adequate for writing text to fit
> in one or two sides of a sheet of paper.  For that I have to use
> LibreOffice -- and I always wish it had the Emacs editing facilities.
>
> --
> 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: Emacs Survey: Toolbars

[Jean Louis]

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

* Christopher Dimech <dimech@gmx.com> [2020-12-24 08:58]:
> I understand what you mean.  Whan I want to print something quick,
> I also have to turn to LibreOffice.  I wrangled that a new major mode
> could suffice, but I am not an knowledgeable enough to be sure.

Really? I left it long ago, I wish I would have some use of
Libreoffice, but don't. Everything I do in Emacs.

For simple printing of text I use Emacs with these commands below to
create PDF files. Then I get those outputs as in attachment. I could
make some function and enlarge or make letters smaller or change
output fonts and so on.

(setq ps-bottom-margin 40)
(setq ps-header-offset 20)
(setq ps-lpr-command "ps-print.sh")
(setq ps-print-footer t)
(setq ps-top-margin 100)
(setq lpr-command "paps_print.sh")

ps-print.sh:

#!/bin/bash
tmpdir=/home/data1/protected/tmp/muttprint/
mkdir -p $tmpdir
cd $tmpdir
file=$tmpdir/$(date +'%F-%T-%A')
#highlight --syntax=lisp --page-color -O pango | paps --markup --font="Monospace 11" > $file.ps
cat > $file.ps
#gv $file.ps
# paps --font="DejaVu Sans Mono 11" > $file.ps
ps2pdf14 $file.ps
exec zathura $file.pdf 2> /dev/null &

paps_print.sh:

#!/bin/bash
tmpdir=/home/data1/protected/tmp/muttprint/
mkdir -p $tmpdir
cd $tmpdir
file=$tmpdir/$(date +'%F-%T-%A')
#highlight --syntax=lisp --page-color -O pango | paps --markup --font="Monospace 11" > $file.ps
paps > $file.ps
#gv $file.ps
# paps --font="DejaVu Sans Mono 11" > $file.ps
ps2pdf14 $file.ps
zathura $file.pdf 2> /dev/null &



[-- Attachment #2: 2020-12-24-09:28:16-Thursday.pdf --]
[-- Type: application/pdf, Size: 239995 bytes --]

[-- Attachment #3: 2020-12-24-09:28:44-Thursday.pdf --]
[-- Type: application/pdf, Size: 10747 bytes --]

Re: Emacs Survey: Toolbars

[Dmitry Gutov]

On 15.12.2020 17:33, Lars Ingebrigtsen wrote:
> Óscar Fuentes<ofv@wanadoo.es>  writes:
> 
>>> I don't think that's a good argument for having a GUI element that few
>>> people like,
>> We have no data to support that.
> I know you're being funny, but: The only data we have does support that.
> 

I think everyone here can agree that we need both more and better data.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 9:58 PM
> From: "Dmitry Gutov" <dgutov@yandex.ru>
> To: "Lars Ingebrigtsen" <larsi@gnus.org>, "Óscar Fuentes" <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> On 15.12.2020 17:33, Lars Ingebrigtsen wrote:
> > Óscar Fuentes<ofv@wanadoo.es>  writes:
> > 
> >>> I don't think that's a good argument for having a GUI element that few
> >>> people like,
> >> We have no data to support that.
> > I know you're being funny, but: The only data we have does support that.
> > 
> 
> I think everyone here can agree that we need both more and better data.
 
Wrong Rationalism.  We would be simply be provisioning to a subset of people
based on the trends in society.  It would not be primarily about software 
freedom.  The focus must on the work we should do, rather that disregarding
minority shareholders as done in the corporate world.  For instance, catering
for users with limitations has almost always been about the few - so almost 
nobody cares about that.

For instance, there is only one face theme that adequately passes 
International Accessibility Standards - Modus-Themes. Should
Modus-Themes be the default face for Emacs? - Absolutely!

Christopher

 
 

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 3:17 PM
> From: "Eric S Fraga" <e.fraga@ucl.ac.uk>
> To: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Although I disabled the toolbar when it first appeared (in the dim and
> distant past), I think it's a good idea to leave them on by
> default.  They are easy enough to disable and provide help for the true
> neophyte.  In fact, learning how to disable the toolbar is probably a
> good first exercise in customizing your Emacs!

Quite correct.  If we really want to modernise emacs, we got to become
serious.  There is a section of people who do not want graphical
elements, and the question was there mainly to appease programmers
who want old style customisation (no menu, no scrollbars, etc).

Toolbars are there so people who use the mouse can enable frequently
used commands using the mouse.  If the plan is enhancement, then.

1. Let Emacs enable people to add things to the toolbar for commands,
   without having to use elisp programming.  The survey suggests that
   those focused on elisp are a minority.

> Eric S Fraga via Emacs 28.0.50 & org 9.4 on Debian bullseye/sid
>
>
>

Re: Emacs Survey: Toolbars

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

  > 1. Let Emacs enable people to add things to the toolbar for commands,
  >    without having to use elisp programming.  The survey suggests that
  >    those focused on elisp are a minority.

We have non-Lisp ways of making key bindings -- M-x global-set-key,
for instance.  If that is inconvenient or unobvious to use with the
toolbar, can we make it convenient and obvious?

Eli said:

  > If we want to appear by default more like other GUI apps out there,
  > then we should bite the bullet and show some widget that allows to
  > toggle on/off those parts of the UI (tool bar, menu bar, scroll bars,
  > etc.), like they do.

I agree.

Can we arrange a way to program such dialogs from Lisp?
That would be an elegant way to solve all these UI problems.
We tried to do this with Customize, but it doesn't equal the
smoothness and elegance of the customization GUIs of other programs.





-- 
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: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 16 Dec 2020 00:44:08 -0500
> Cc: emacs-devel@gnu.org, e.fraga@ucl.ac.uk
> 
>   > If we want to appear by default more like other GUI apps out there,
>   > then we should bite the bullet and show some widget that allows to
>   > toggle on/off those parts of the UI (tool bar, menu bar, scroll bars,
>   > etc.), like they do.
> 
> I agree.
> 
> Can we arrange a way to program such dialogs from Lisp?
> That would be an elegant way to solve all these UI problems.

I'd expect modern toolkits to have such a widget ready for use, given
the attitude of the GUI applications nowadays.

Re: Emacs Survey: Toolbars

[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 expect modern toolkits to have such a widget ready for use, given
  > the attitude of the GUI applications nowadays.

I do, too.  Is there a GTK expert here?

-- 
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: Emacs Survey: Toolbars

[Stefan Monnier]

> Of 7.3K respondents, 5K disable toolbars, which is more than two
> thirds.  So perhaps toolbars should default to off?  I know toolbars
> were all the rage in the 90s, but that's apparently not the case now.

FWIw, I believe the toolbar should behave a bit more like the
header-line: it should not "default to off" but instead it should only
exist in those buffers where it is useful.

IMO a toolbar should contain things that are used often, and by "often"
I don't mean "in most sessions" but rather often enough that the time
taken to pick it from the menu-bar would be excessive.
Contrary to the menu-bar, the toolbar is not a good way to advertise
Emacs's functionality because there just isn't enough room to put that
info, so to justify its existence it should be *useful*.

For most major modes, it's hard to find a justification for a toolbar,
and for some major modes, OTOH, it's a no-brainer (e.g. mpc.el).
But I don't think we've done a good job of making use of the toolbar for
the middle ground.

IOW, the current tool-bar is a mechanism that we haven't really tried
hard to make use of it.  Maybe instead of "actions" it should mostly
contain "toggle buttons" for minor modes (and maybe these would need to
be new minor modes, since most of our minor modes are designed under
the principle that they're not toggle at a high frequency)?



        Stefan

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

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

> For most major modes, it's hard to find a justification for a toolbar,
> and for some major modes, OTOH, it's a no-brainer (e.g. mpc.el).
> But I don't think we've done a good job of making use of the toolbar for
> the middle ground.

True, there are modes where the toolbar may be useful, and a media
player might be one of them.  And prev/next/reload in a browser may be
something people might use.  But there aren't a lot of these modes, and
you may as well put the buttons in the mode line, which is already
there, and which nobody much disables.

If you compare the Emacs mode line with a modern "tool bar" (for
instance, the Crome line at the top), they're not that different.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Stefan Kangas]

(I had a look at this recent megathread, as nothing actionable seems to
have come out of it.)

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> For most major modes, it's hard to find a justification for a toolbar,
>> and for some major modes, OTOH, it's a no-brainer (e.g. mpc.el).
>> But I don't think we've done a good job of making use of the toolbar for
>> the middle ground.
>
> True, there are modes where the toolbar may be useful, and a media
> player might be one of them.  And prev/next/reload in a browser may be
> something people might use.

How about introducing a new variable with the tentative name
`this-mode-wants-toolbars' that defaults to nil?  If it is nil, there
are no toolbars.  This variable can then be set to t when someone has
made a toolbar that they know will be useful.

That way, there is less need for users to disable the toolbar globally
(unless you really want to), and they can benefit from this feature
where it is actually in a useful state.

One obvious drawback of this proposal is that it's slightly jarring when
the toolbar appears and disappears when switching between windows.
Perhaps we could show it if it is enabled in any buffer in a window on
the current frame?

> But there aren't a lot of these modes, and
> you may as well put the buttons in the mode line, which is already
> there, and which nobody much disables.

I tend to agree.  The above proposal would leave this to the mode
author to decide.

(Well, in reality, the overwhelming majority run with no toolbars anyway.
So if you want your controls seen you should probably still put them in
the mode line.)

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 25 Feb 2021 09:50:29 -0600
> Cc: emacs-devel@gnu.org
> 
> How about introducing a new variable with the tentative name
> `this-mode-wants-toolbars' that defaults to nil?  If it is nil, there
> are no toolbars.  This variable can then be set to t when someone has
> made a toolbar that they know will be useful.

That makes little sense to me.  Other applications that show tool bars
don't make them appear and disappear, only change as appropriate for
the context.

> One obvious drawback of this proposal is that it's slightly jarring when
> the toolbar appears and disappears when switching between windows.

Exactly.

> Perhaps we could show it if it is enabled in any buffer in a window on
> the current frame?

So you basically want NOT to make it disappear?  Then why make it
disappear?

Re: Emacs Survey: Toolbars

[Stefan Monnier]

> That makes little sense to me.  Other applications that show tool bars
> don't make them appear and disappear, only change as appropriate for
> the context.

Which applications are you thinking of here, that would be comparable to
Emacs (i.e. are part music-player, part text editor, part hex editor, part
IRC client, ...)?

>> One obvious drawback of this proposal is that it's slightly jarring when
>> the toolbar appears and disappears when switching between windows.
> Exactly.

I think the solution is to have toolbars inside the window's text,
rather than attached to the frame.

For mpc.el I played with the idea of building up a "toolbar" that gets
inserted into the buffer, but I didn't the time needed to get something
good enough.


        Stefan

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  larsi@gnus.org,
>   emacs-devel@gnu.org
> Date: Thu, 25 Feb 2021 14:03:26 -0500
> 
> > That makes little sense to me.  Other applications that show tool bars
> > don't make them appear and disappear, only change as appropriate for
> > the context.
> 
> Which applications are you thinking of here, that would be comparable to
> Emacs (i.e. are part music-player, part text editor, part hex editor, part
> IRC client, ...)?

I don't see how this is relevant.  The tool bar is part of the GUI,
which functions are shown there is immaterial.

> >> One obvious drawback of this proposal is that it's slightly jarring when
> >> the toolbar appears and disappears when switching between windows.
> > Exactly.
> 
> I think the solution is to have toolbars inside the window's text,
> rather than attached to the frame.

Is this practical?  Windows can be very narrow, and change dimensions
much more frequently in Emacs than frames.  Tool bars don't live well
with frequent changes in dimensions.

If someone wants to turn tool bar off, let them do that.  We don't
need to turn the Emacs appearance upside down just because of some
fashion: we already support that fashion.

RE: [External] : Re: Emacs Survey: Toolbars

[Drew Adams]

> If someone wants to turn tool bar off, let them do that.  We don't
> need to turn the Emacs appearance upside down just because of some
> fashion: we already support that fashion.

(This is not what you're discussing now, I
guess, but it can affect whether a user's
choice of whether to use tool bars.)

I'll just mention again that users can have a
popup tool bar.  IOW, show it only on demand,
for a single action.

Also, ability to show the tool-bar only for
the current frame.

https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus

This or a similar feature could be added to
vanilla Emacs.

Re: Emacs Survey: Toolbars

[Stefan Monnier]

>> > That makes little sense to me.  Other applications that show tool bars
>> > don't make them appear and disappear, only change as appropriate for
>> > the context.
>> Which applications are you thinking of here, that would be comparable to
>> Emacs (i.e. are part music-player, part text editor, part hex editor, part
>> IRC client, ...)?
> I don't see how this is relevant.  The tool bar is part of the GUI,
> which functions are shown there is immaterial.

It's relevant in the fact that some of those applications may come with
a toolbar while others don't, so a single application that provides
access too all those facilities (like Emacs) may want to sometimes show
a toolbar and sometimes not.

>> I think the solution is to have toolbars inside the window's text,
>> rather than attached to the frame.
> Is this practical?  Windows can be very narrow, and change dimensions
> much more frequently in Emacs than frames.  Tool bars don't live well
> with frequent changes in dimensions.
>
> If someone wants to turn tool bar off, let them do that.  We don't
> need to turn the Emacs appearance upside down just because of some
> fashion: we already support that fashion.

I'm suggesting to *add* "in-buffer" toolbars (hopefully as a pure-ELisp
feature).  


        Stefan

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stefankangas@gmail.com,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Thu, 25 Feb 2021 17:24:59 -0500
> 
> >> Which applications are you thinking of here, that would be comparable to
> >> Emacs (i.e. are part music-player, part text editor, part hex editor, part
> >> IRC client, ...)?
> > I don't see how this is relevant.  The tool bar is part of the GUI,
> > which functions are shown there is immaterial.
> 
> It's relevant in the fact that some of those applications may come with
> a toolbar while others don't

Which significant applications don't have a tool bar at all,
i.e. don't even have an option to display a tool bar?

> so a single application that provides access too all those
> facilities (like Emacs) may want to sometimes show a toolbar and
> sometimes not.

By what logic?

The tool bar in Emacs is very like the menu bar: it provides quick and
easy access to some frequently-used functions.  Which application
doesn't have any such function to justify the lack of a tool bar?

> > If someone wants to turn tool bar off, let them do that.  We don't
> > need to turn the Emacs appearance upside down just because of some
> > fashion: we already support that fashion.
> 
> I'm suggesting to *add* "in-buffer" toolbars (hopefully as a pure-ELisp
> feature).  

So your suggestion is to have _both_ the frame-global tool bar and
another tool bar displayed in some windows?  That'd be fine with me
(we already have some modes display a header-line, which is a kind-of
tool bar, and we now have the tab-line as well, so we have similar
functionality already).

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

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

> I think the solution is to have toolbars inside the window's text,
> rather than attached to the frame.

Yeah, I think that's the way forward.  Having the toolbar in the window
will allow much greater flexibility, and allow users to switch the
toolbar on in modes where it makes sense.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: [External] : Re: Emacs Survey: Toolbars

[Drew Adams]

> > I think the solution is to have toolbars inside the window's text,
> > rather than attached to the frame.
> 
> Yeah, I think that's the way forward.  Having the toolbar in the window
> will allow much greater flexibility, and allow users to switch the
> toolbar on in modes where it makes sense.

By "inside the window's text" do you mean anywhere
within it, so for example a user could move it
around within that space?  Or do you mean something
more like what Eli suggested - perhaps handled like
a header-line is handled?

In what you imagine, would more than one such tool
bar be possible within the window's text area?

I guess my overall request here is whether you can
perhaps flesh out more of what you (plural) have
in mind.

Re: [External] : Re: Emacs Survey: Toolbars

[Stefan Monnier]

> By "inside the window's text" do you mean anywhere
> within it, so for example a user could move it

I don't know what other people mean, but what I'm thinking of is
reflected in the chunk of code below I started writing some years ago.
You can `insert` the result into the buffer to put a toolbar wherever
you want (don't expect miracles: it has loads of shortcomings).


        Stefan


(defun tool-bar-to-string (&optional map)
  (let ((res ""))
    (map-keymap
     (lambda (k v)
       (when (eq (car v) 'menu-item)
         (let* ((name (nth 1 v))            ;Unused, AFAICT.
                (cmd (nth 2 v))
                (plist (nthcdr (if (consp (nth 3 v)) 4 3) v))
                (help-echo (plist-get plist :help))
                (image     (plist-get plist :image))
                (button (propertize " " 'help-echo help-echo
                                    'keymap (let ((map (make-sparse-keymap)))
                                              (define-key map [mouse-1] cmd)
                                              map)
                                    'face 'tool-bar ;; 'custom-button
                                    'mouse-face 'custom-button-mouse
                                    'rear-nonsticky '(display keymap help-echo)
                                    'display image)))
           (setq res (concat res (propertize " " 'display '(space :width 1)
                                             'face 'custom-button
                                             )
                             button)))))
     (or map (key-binding [tool-bar])))
    res))

*Menu* buffer

[Tomas Hlavaty]

On Fri 26 Feb 2021 at 11:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> (defun tool-bar-to-string (&optional map)

interesting

Is there something like this for menu?  I would like to have a *Menu*
buffer instead of menu bar.

Re: *Menu* buffer

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Sat, 27 Feb 2021 01:28:40 +0100
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> On Fri 26 Feb 2021 at 11:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > (defun tool-bar-to-string (&optional map)
> 
> interesting
> 
> Is there something like this for menu?  I would like to have a *Menu*
> buffer instead of menu bar.

You should be able to do something like that with header-line.

Re: *Menu* buffer

[David Masterson]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tomas Hlavaty <tom@logand.com>
>> Date: Sat, 27 Feb 2021 01:28:40 +0100
>> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> 
>> On Fri 26 Feb 2021 at 11:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> > (defun tool-bar-to-string (&optional map)
>> 
>> interesting
>> 
>> Is there something like this for menu?  I would like to have a *Menu*
>> buffer instead of menu bar.
>
> You should be able to do something like that with header-line.

I was thinking about this myself and wondering if you could do it with a
multi-layer hydra where you have a top-level hydra that you add/remove
lower-level hydras specific to the major/minor modes you're in.

Just a thought at the moment...
-- 
David Masterson

Re: Emacs Survey: Toolbars

[martin rudalics]

 > One obvious drawback of this proposal is that it's slightly jarring when
 > the toolbar appears and disappears when switching between windows.

Note that with GTK the outer frame shrinks/expands when the toolbar is
removed/added.  Not talking about the GTK3 warnings when the toolbar
doesn't fit ...

martin

Re: Emacs Survey: Toolbars

[Clément Pit-Claudel]

On 12/15/20 9:29 AM, Stefan Monnier wrote:
>> Of 7.3K respondents, 5K disable toolbars, which is more than two
>> thirds.  So perhaps toolbars should default to off?  I know toolbars
>> were all the rage in the 90s, but that's apparently not the case now.
> 
> FWIw, I believe the toolbar should behave a bit more like the
> header-line: it should not "default to off" but instead it should only
> exist in those buffers where it is useful.

I like that take.  I tried to do this in fstar-mode: by default, opening an F* file will also re-enable the toolbar in F* buffers even if it was previously hidden by the user, and most users don't seem to re-disable it.  In fact, many users seem to use them even for features that are bound to convenient keys.  I have seen the same thing for beginner users of Proof General (PG also includes specialized toolbars).

RE: Emacs Survey: Toolbars

[Drew Adams]

> FWIw, I believe the toolbar should behave a bit more like the
> header-line: it should not "default to off" but instead it should only
> exist in those buffers where it is useful.
> 
> IMO a toolbar should contain things that are used often, and by "often"
> I don't mean "in most sessions" but rather often enough that the time
> taken to pick it from the menu-bar would be excessive.
> Contrary to the menu-bar, the toolbar is not a good way to advertise
> Emacs's functionality because there just isn't enough room to put that
> info, so to justify its existence it should be *useful*.
> 
> For most major modes, it's hard to find a justification for a toolbar,
> and for some major modes, OTOH, it's a no-brainer (e.g. mpc.el).
> But I don't think we've done a good job of making use of the toolbar for
> the middle ground.
> 
> IOW, the current tool-bar is a mechanism that we haven't really tried
> hard to make use of it.  Maybe instead of "actions" it should mostly
> contain "toggle buttons" for minor modes (and maybe these would need to
> be new minor modes, since most of our minor modes are designed under
> the principle that they're not toggle at a high frequency)?

FWIW:

1. I agree with what Stefan said.  Buffer-specific
if possible.  Most modes don't justify it on by
default.  (But I don't think it matters whether we
decide that tool-bar buttons should only or mainly
be for toggling something.)

2. I think that the default "on" state should be
that provided by `tool-bar-pop-up-mode' from my
library `tool-bar+.el' (or similar).

https://www.emacswiki.org/emacs/ToolBar#tool-bar-pop-up-mode

tl;dr: Save space without sacrificing discoverability
or availability of the tool-bar.


Advantage relative to showing the tool-bar:

 Instead of sacrificing an entire line of tool-bars
 (vertical space), you sacrifice the horizontal space
 of an additional menu-bar menu.

 Not a real menu, but a menu name that's really a
 button that opens the tool-bar for a one-off action.

Advantage relative to not showing the tool-bar:

 Discoverability.

The tool-bar+.el code (any or all of it) could be
added to Emacs.  Or the design can be used as
inspiration for something similar.
___


The same library also provides another minor mode
for the tool-bar: `tool-bar-here-mode'.  This is
the same as 'tool-bar-mode', except that it affects
only the current frame.  This saves real estate on
frames other than those where you've chosen to have
a tool-bar.

Re: Emacs Survey: Toolbars

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-12-15 17:42]:
> For most major modes, it's hard to find a justification for a toolbar,
> and for some major modes, OTOH, it's a no-brainer (e.g. mpc.el).
> But I don't think we've done a good job of making use of the toolbar for
> the middle ground.

For your insights and considerations1, personally toolbar is definitely
great when working with the mouse and interacting with other
applications. Especially when trying to work with one hand it is
great. For staff members who need to save files or open new notes
quickly it is great. Even more icons would be great to have, there is
so much more space. Tool bars make Emacs user friendly for majority of
new users as people are used to using mouse.

It should even get its customize or defcustom possibility.

Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 7:44 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Stefan Monnier" <monnier@iro.umontreal.ca>
> Cc: "Lars Ingebrigtsen" <larsi@gnus.org>, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> * Stefan Monnier <monnier@iro.umontreal.ca> [2020-12-15 17:42]:
> > For most major modes, it's hard to find a justification for a toolbar,
> > and for some major modes, OTOH, it's a no-brainer (e.g. mpc.el).
> > But I don't think we've done a good job of making use of the toolbar for
> > the middle ground.
>
> For your insights and considerations1, personally toolbar is definitely
> great when working with the mouse and interacting with other
> applications. Especially when trying to work with one hand it is
> great. For staff members who need to save files or open new notes
> quickly it is great. Even more icons would be great to have, there is
> so much more space. Tool bars make Emacs user friendly for majority of
> new users as people are used to using mouse.

Absolutely.  The argument is not about using the keyboard or using the mouse.
In regards to strain injury, there are two important aspects:

1. Not stretch fingers
2. Not move wrist

In addition, if the user normally uses keyboard, it makes sense that
he continues using the keyboard, rather than having to switch to the
mouse.  This is largely agreed among programmers.

The problem started when programmers starting demanding for Emacs
to focus only on the keyboard.

For those who primarily use the mouse, they should continue to use
the mouse for most things where the user could use the mouse.

As regards development, Emacs could have minor-modes for the
following categarisations:

1. Mainly using the Keyboard
2. Mainly using the Mouse
3. Mainly using Querty
4. Mainly using Dvorak

Furthermore, most people disregard Accessibility.  For instance, KMouseTool clicks the mouse
whenever the mouse cursor pauses briefly. It was designed to help those with repetitive strain
injuries, for whom pressing buttons hurts. KMouseTool also eliminates the pain caused by clicking
the mouse, helping many people to use the computer without pain.

And to work with the mouse makes menu-bar a definite requirement - no arguments there.

> It should even get its customize or defcustom possibility.
>
>

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 15 Dec 2020 06:30:20 +0100
> 
> Of 7.3K respondents, 5K disable toolbars, which is more than two
> thirds.  So perhaps toolbars should default to off?  I know toolbars
> were all the rage in the 90s, but that's apparently not the case now.
> 
> Opinions?

If we want to appear by default more like other GUI apps out there,
then we should bite the bullet and show some widget that allows to
toggle on/off those parts of the UI (tool bar, menu bar, scroll bars,
etc.), like they do.

IOW, turning off the tool bar by default and leaving the users with
"M-x tool-bar-mode" to turn it on is IMO a step back in usability
which will leave us with a poorer UI.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 5:26 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Lars Ingebrigtsen" <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Tue, 15 Dec 2020 06:30:20 +0100
> >
> > Of 7.3K respondents, 5K disable toolbars, which is more than two
> > thirds.  So perhaps toolbars should default to off?  I know toolbars
> > were all the rage in the 90s, but that's apparently not the case now.
> >
> > Opinions?
>
> If we want to appear by default more like other GUI apps out there,
> then we should bite the bullet and show some widget that allows to
> toggle on/off those parts of the UI (tool bar, menu bar, scroll bars,
> etc.), like they do.
>
> IOW, turning off the tool bar by default and leaving the users with
> "M-x tool-bar-mode" to turn it on is IMO a step back in usability
> which will leave us with a poorer UI.

I fully agree with Eli Zaretskii.  We have really started on very bad
ideas.  Debating about disabling or enabling a toolbar (in general, the
question was about disabling graphical tools, completely antithetical to
modernisation) is of no real value.

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If we want to appear by default more like other GUI apps out there,
> then we should bite the bullet and show some widget that allows to
> toggle on/off those parts of the UI (tool bar, menu bar, scroll bars,
> etc.), like they do.

Yeah, the natural thing would be to put that on a pop-up menu on
mouse-3 -- I think that's a pretty common UI pattern?  And I see that
mouse-3 isn't bound on any of those elements now.

And perhaps there should be some menu to toggle the tool bar/scroll bars
on/off?  That might be there already somewhere, but not in the menu
where it would make sense -- the Options menu...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 16 Dec 2020 10:14:45 +0100
> 
> And perhaps there should be some menu to toggle the tool bar/scroll bars
> on/off?  That might be there already somewhere, but not in the menu
> where it would make sense -- the Options menu...

It's under Options->Show/Hide.

Re: Emacs Survey: Toolbars

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 16 Dec 2020 10:14:45 +0100
>> 
>> And perhaps there should be some menu to toggle the tool bar/scroll bars
>> on/off?  That might be there already somewhere, but not in the menu
>> where it would make sense -- the Options menu...
>
> It's under Options->Show/Hide.

Should we take this opportunity to either auto-save config changes
made via the menus, or put a big red button somewhere saying 'click
here to save settings', or prompt the user to save them when exiting?

Robert

(Iʼve never really liked the toolbar enable/disable menu. How many gui
applications these days let you put the toolbar anywhere other than at
the top?)

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
> Date: Wed, 16 Dec 2020 17:18:33 +0100
> 
> Should we take this opportunity to either auto-save config changes
> made via the menus, or put a big red button somewhere saying 'click
> here to save settings', or prompt the user to save them when exiting?

What's wrong with Options->Save Options?

Re: Emacs Survey: Toolbars

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  emacs-devel@gnu.org
>> Date: Wed, 16 Dec 2020 17:18:33 +0100
>> 
>> Should we take this opportunity to either auto-save config changes
>> made via the menus, or put a big red button somewhere saying 'click
>> here to save settings', or prompt the user to save them when exiting?
>
> What's wrong with Options->Save Options?

Nothing, except that people have been conditioned to expect that
changes in options get saved automatically, so we could do that for
them if they make the changes via the menus. On a related note, perhaps
'save options' should be the last entry in the Options menu, to make
it stand out more.

Robert

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 17 Dec 2020 09:20:32 +0100
> 
> > What's wrong with Options->Save Options?
> 
> Nothing, except that people have been conditioned to expect that
> changes in options get saved automatically, so we could do that for
> them if they make the changes via the menus.

Not sure I'd like it: it would make it harder to try an option without
committing to using it.

> On a related note, perhaps 'save options' should be the last entry
> in the Options menu, to make it stand out more.

Its current place is what it is because the items below it don't
belong to "Options" saved by "Save Options".  We could add some
delimiter to make that more evident, but it isn't like the place is
random or not well thought of.

Re: Emacs Survey: Toolbars

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 17 Dec 2020 09:20:32 +0100
>> 
>> > What's wrong with Options->Save Options?
>> 
>> Nothing, except that people have been conditioned to expect that
>> changes in options get saved automatically, so we could do that for
>> them if they make the changes via the menus.
>
> Not sure I'd like it: it would make it harder to try an option without
> committing to using it.
>

Yes, but as I said: itʼs what people have been conditioned to
expect. Or we could limit it to only visual things like
toolbars,scrollbars etc.

>> On a related note, perhaps 'save options' should be the last entry
>> in the Options menu, to make it stand out more.
>
> Its current place is what it is because the items below it don't
> belong to "Options" saved by "Save Options".  We could add some
> delimiter to make that more evident, but it isn't like the place is
> random or not well thought of.

I guess we could add another separator above it.

Robert

Re: Emacs Survey: Toolbars

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

>> Its current place is what it is because the items below it don't
>> belong to "Options" saved by "Save Options".  We could add some
>> delimiter to make that more evident, but it isn't like the place is
>> random or not well thought of.
>
> I guess we could add another separator above it.
>

*below* it. Menu definitions are done in reverse order.

Re: Emacs Survey: Toolbars

[Gregory Heytings via Emacs development discussions.]

>> On a related note, perhaps 'save options' should be the last entry in 
>> the Options menu, to make it stand out more.
>
> Its current place is what it is because the items below it don't belong 
> to "Options" saved by "Save Options".  We could add some delimiter to 
> make that more evident, but it isn't like the place is random or not 
> well thought of.
>

I'd suggest to give that menu entry a more explicit name, "Save Options 
Above" or "Save Above Options", with a separator above (apparently that 
one is already present) and below.

Re: Emacs Survey: Toolbars

[Robert Pluim]

Gregory Heytings via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

>>> On a related note, perhaps 'save options' should be the last entry
>>> in the Options menu, to make it stand out more.
>>
>> Its current place is what it is because the items below it don't
>> belong to "Options" saved by "Save Options".  We could add some
>> delimiter to make that more evident, but it isn't like the place is
>> random or not well thought of.
>>
>
> I'd suggest to give that menu entry a more explicit name, "Save
> Options Above" or "Save Above Options", with a separator above
> (apparently that one is already present) and below.

"Save Changed Options"? I feel like I may have unwisely wandered too
close to the bike shed here. :-)

Robert

RE: Emacs Survey: Toolbars

[Drew Adams]

> >> Should we take this opportunity to either auto-save config changes
> >> made via the menus, or put a big red button somewhere saying 'click
> >> here to save settings', or prompt the user to save them when exiting?
> >
> > What's wrong with Options->Save Options?
> 
> Nothing, except that people have been conditioned to expect that
> changes in options get saved automatically, 

I assume you mean _some_ people.

> so we could do that for
> them if they make the changes via the menus. On a related note, perhaps
> 'save options' should be the last entry in the Options menu, to make
> it stand out more.

If some more than a few people really do expect
setting (option) changes to be saved automatically,
then we could add an option (!) (or a minor mode)
that does that.  Turn on that option, and thereafter
all changes you make to options, faces, themes, etc.
get saved automatically.

Note that that behavior can get in the way of user
experimentation.  Not that it's necessarily limiting
- it's just a different approach.

In sum, if we want to support automatic saving of
every setting change then we should do so optionally
(and opt-in), not just switch to that for everyone.

Re: Emacs Survey: Toolbars

[Alfred M. Szmidt]

   If some more than a few people really do expect
   setting (option) changes to be saved automatically,
   then we could add an option (!) (or a minor mode)
   that does that.  Turn on that option, and thereafter
   all changes you make to options, faces, themes, etc.
   get saved automatically.

FWIW (tiny data point) I know many users that are suprised about the
fact that toggling an option in the menu-bar doesn't save it
permanently.

   Note that that behavior can get in the way of user
   experimentation.  Not that it's necessarily limiting
   - it's just a different approach.

It would be nice if one could see what options one set (via the
toolbar); then one could see what one is experimenting with. 

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Thursday, December 17, 2020 at 7:10 PM
> From: "Alfred M. Szmidt" <ams@gnu.org>
> To: "Drew Adams" <drew.adams@oracle.com>
> Cc: rpluim@gmail.com, eliz@gnu.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
>    If some more than a few people really do expect
>    setting (option) changes to be saved automatically,
>    then we could add an option (!) (or a minor mode)
>    that does that.  Turn on that option, and thereafter
>    all changes you make to options, faces, themes, etc.
>    get saved automatically.
>
> FWIW (tiny data point) I know many users that are suprised about the
> fact that toggling an option in the menu-bar doesn't save it
> permanently.
>
>    Note that that behavior can get in the way of user
>    experimentation.  Not that it's necessarily limiting
>    - it's just a different approach.

The behaviour is akin to cycling color themes without actually changing
the theme permanently.

It is not invariably evident that the contrasts between emacs and the
behaviour of other applications is bad.  Emacs gives users much more
control of what happens.  Thusly, it is quite easy to end up messing
your system with things that ultimately you could not want.

Experimentation, either through User Hacking or through Emacs Packages
is quite a regular thing.

> It would be nice if one could see what options one set (via the
> toolbar); then one could see what one is experimenting with.

I like the idea.

Re: Emacs Survey: Toolbars

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

  > > Nothing, except that people have been conditioned to expect that
  > > changes in options get saved automatically, 

  > I assume you mean _some_ people.

Would each you please take a deep breath, and respond more kindly from now on?

-- 
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: Emacs Survey: Toolbars

[Drew Adams]

> > > Nothing, except that people have been conditioned to expect that
> > > changes in options get saved automatically,
> > I assume you mean _some_ people.
> 
> Would each you please take a deep breath, and respond
> more kindly from now on?

Would you please take a deep breath?  I don't think
there was anything unkind in either what Robert said
or in my reply to him.

Did you actually read what each of us said?  The point
of my emphasis on "some" was elaborated in the rest of
what I said, the point of which was that we can easily
accommodate _both_ expectations of saving automatically
and saving only on demand.

I don't even see any disagreement in what we were each
saying.  Some people _are_ used to automatic saving,
and we can accommodate that while also giving others
what they expect (which is what we have now).

Re: RE: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Friday, December 18, 2020 at 7:36 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: rms@gnu.org
> Cc: rpluim@gmail.com, eliz@gnu.org, emacs-devel@gnu.org
> Subject: RE: Emacs Survey: Toolbars
>
> > > > Nothing, except that people have been conditioned to expect that
> > > > changes in options get saved automatically,
> > > I assume you mean _some_ people.
> >
> > Would each you please take a deep breath, and respond
> > more kindly from now on?
>
> Would you please take a deep breath?  I don't think
> there was anything unkind in either what Robert said
> or in my reply to him.
>
> Did you actually read what each of us said?  The point
> of my emphasis on "some" was elaborated in the rest of
> what I said, the point of which was that we can easily
> accommodate _both_ expectations of saving automatically
> and saving only on demand.

That is also my point on toolbar, it is not useless and can support both.
The current problem is that the toolbar is attached to the Emacs frame,
rather than using another frame.  There is also the possibility of dynamically
adding a new MenuItem.

> I don't even see any disagreement in what we were each
> saying.  Some people _are_ used to automatic saving,
> and we can accommodate that while also giving others
> what they expect (which is what we have now).
>
>

Re: Emacs Survey: Toolbars

[Robert Pluim]

Drew Adams <drew.adams@oracle.com> writes:

>> > > Nothing, except that people have been conditioned to expect that
>> > > changes in options get saved automatically,
>> > I assume you mean _some_ people.
>> 
>> Would each you please take a deep breath, and respond
>> more kindly from now on?
>
> Would you please take a deep breath?  I don't think
> there was anything unkind in either what Robert said
> or in my reply to him.
>

I agree

> Did you actually read what each of us said?  The point
> of my emphasis on "some" was elaborated in the rest of
> what I said, the point of which was that we can easily
> accommodate _both_ expectations of saving automatically
> and saving only on demand.
>

True, although adding an option that says 'save all changes
automatically' will help those who already know how to make
configuration changes permanent. I was aiming more for the subset of
people who donʼt know that yet.

> I don't even see any disagreement in what we were each
> saying.  Some people _are_ used to automatic saving,
> and we can accommodate that while also giving others
> what they expect (which is what we have now).

The only disagreement is whether such an option should be enabled by
default for changes made via the menus, I think.

Robert

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Friday, December 18, 2020 at 9:42 AM
> From: "Robert Pluim" <rpluim@gmail.com>
> To: "Drew Adams" <drew.adams@oracle.com>
> Cc: eliz@gnu.org, rms@gnu.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Drew Adams <drew.adams@oracle.com> writes:
> 
> >> > > Nothing, except that people have been conditioned to expect that
> >> > > changes in options get saved automatically,
> >> > I assume you mean _some_ people.
> >> 
> >> Would each you please take a deep breath, and respond
> >> more kindly from now on?
> >
> > Would you please take a deep breath?  I don't think
> > there was anything unkind in either what Robert said
> > or in my reply to him.
> >
> 
> I agree
> 
> > Did you actually read what each of us said?  The point
> > of my emphasis on "some" was elaborated in the rest of
> > what I said, the point of which was that we can easily
> > accommodate _both_ expectations of saving automatically
> > and saving only on demand.
> >
> 
> True, although adding an option that says 'save all changes
> automatically' will help those who already know how to make
> configuration changes permanent. I was aiming more for the subset of
> people who donʼt know that yet.
> 
> > I don't even see any disagreement in what we were each
> > saying.  Some people _are_ used to automatic saving,
> > and we can accommodate that while also giving others
> > what they expect (which is what we have now).
> 
> The only disagreement is whether such an option should be enabled by
> default for changes made via the menus, I think.

That depends on whether we would people to experiment without messing
up their setup.   For those who experiment with many problems. they
run the risk of forgetting how to revert to their previous configuration.
Perhaps writing the details in a file, and using that if they want to
revert back?
 
> Robert
> 
>

Re: Emacs Survey: Toolbars

[Robert Pluim]

Christopher Dimech <dimech@gmx.com> writes:

>
> That depends on whether we would people to experiment without messing
> up their setup.   For those who experiment with many problems. they
> run the risk of forgetting how to revert to their previous configuration.
> Perhaps writing the details in a file, and using that if they want to
> revert back?

You mean creating a ~/.emacs.d/saved-changes.el file with a menu
command to undo them? I can't judge how useful that would be.

Robert

RE: Emacs Survey: Toolbars

[Drew Adams]

> > The only disagreement is whether such an option should be enabled by
> > default for changes made via the menus, I think.
> 
> That depends on whether we would people to experiment without messing
> up their setup.   For those who experiment with many problems. they
> run the risk of forgetting how to revert to their previous configuration.
> Perhaps writing the details in a file, and using that if they want to
> revert back?

Yes, that was a point I made.

There are good arguments to be made both for and
against auto-saving of option changes.  My message
of a few minutes ago elaborates on this.

Providing for the possibility (choice) of auto-saving
could be a good thing.  Providing flexibility in such
a user choice would be even better.

IOW, even just a choice always/never save all options
could be a step forward, but it's not the best possible
solution.  Options are not all the same, and users
don't all use the same option the same way.

Re: RE: Emacs Survey: Toolbars

[Christopher Dimech]

---------------------
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy


> Sent: Friday, December 18, 2020 at 6:48 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>, "Robert Pluim" <rpluim@gmail.com>
> Cc: eliz@gnu.org, rms@gnu.org, emacs-devel@gnu.org
> Subject: RE: Emacs Survey: Toolbars
>
> > > The only disagreement is whether such an option should be enabled by
> > > default for changes made via the menus, I think.
> >
> > That depends on whether we would people to experiment without messing
> > up their setup.   For those who experiment with many problems. they
> > run the risk of forgetting how to revert to their previous configuration.
> > Perhaps writing the details in a file, and using that if they want to
> > revert back?
>
> Yes, that was a point I made.
>
> There are good arguments to be made both for and
> against auto-saving of option changes.  My message
> of a few minutes ago elaborates on this.
>
> Providing for the possibility (choice) of auto-saving
> could be a good thing.  Providing flexibility in such
> a user choice would be even better.

Then we provide the flexibility.

> IOW, even just a choice always/never save all options
> could be a step forward, but it's not the best possible
> solution.  Options are not all the same, and users
> don't all use the same option the same way.
>
>

RE: Emacs Survey: Toolbars

[Drew Adams]

> The only disagreement is whether such an option should be
> enabled by default for changes made via the menus, I think.

There's not even any real disagreement there, I think.

My reflex is to not change default behavior willy
nilly, but case-by-case is the right approach to take
when considering such changes.
___

My opinion about this general question is that both
behaviors can be useful.  And each is typically more
useful for some kinds of option changing/setting.

A behavior that I'm likely to toggle often within a
given Emacs session is one whose last state I
typically do not want to save for the next Emacs
session.

A behavior that I'm not likely to change often is one
whose last state I might well want to save for the
next browser session.  (Or I might not.)

For the latter, think of web browser settings.  When
I change such a setting I don't need to explicitly
"save" settings - and that's "natural" behavior.
That's the kind of thing I think you were thinking of
when saying that users are used to such behavior and
expect it.

[You can see that not only do I think this applies
to _some_ users.  I think it can apply to the _same_
user _some_ of the time.]

For the former, think of, say, toggling option
`case-fold-search'.  I might do that many times in
the same Emacs session.  I generally want its saved
value to reflect my preference for the _default_
behavior (which in my case is case-sensitive search).
I don't want it to reflect the last case-fold state
of my last search in my last session.

Note that vanilla Emacs goes out of its way to have
most of its commands that toggle behavior such as case
folding NOT change the option value.  To toggle the
option value you use a specific command for that.
E.g., when you toggle case folding during Isearch that
doesn't change the option value.
___

Personally, I think that for some commands it can
make sense to let users toggle _either_ the option
value or a temporary state.  (Note: toggling an
option value is different from doing that and also
saving the value.  That too can be a user preference
for this or that option.)

For example, in Isearch+ there's even an option,
`isearchp-toggle-option-flag', that controls this:

 Non-nil means Isearch toggling commands can affect option values.
 If nil, the option value remains unchanged - the effect is temporary.

 Applies to toggle commands for behavior that has an associated user
 option.  Currently this means `M-s i' (`isearch-toggle-invisible') and
 `M-c' (`isearch-toggle-case-fold').

If that option is nil then toggling case folding is
temporary, i.e., for the current Isearch invocation
only.  If non-nil then the change persists for future
invocations in the same session.

Similarly, `isearchp-auto-keep-filter-predicate-flag':

 Non-nil means automatically apply `C-z s'.
 Changes to `isearch-filter-predicate' are automatically kept for
 subsequent searches in this Emacs session when you exit Isearch'.
 You can toggle this option using `C-z S during Isearch.

Re: Emacs Survey: Toolbars

[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 read these words

    > Nothing, except that people have been conditioned to expect that
    > changes in options get saved automatically, 

    I assume you mean _some_ people.

and saw that things were getting snarky.  "I assume you mean" is a
snarky way of disagreeing if it isn't reporting a typing error.

So I said,

    Would each you please take a deep breath, and respond
    more kindly from now on?

I guess you took that as an attack, rather than as an exhortation,
because you responded by throwing that perceived attack back at me:

    Would you please take a deep breath?

I did as you suggested, and on second reading I agree
that Robert Pluim's words were not unkind.  They seemed
that way when I first read them.  Sorry, Robert.

You continued with

                                          I don't think
    there was anything unkind in either what Robert said
    or in my reply to him.

    Did you actually read what each of us said?

Of course.  But only the parts that I cited.

I didn't read the whole messages, or any of the whole messages in that
subthread, because I'm not participating in discussing that particular
question.  If I wanted to participate, I'd have to read the points
made about it.  I decided it was easier just to say nothing about it.

  >   The point
  > of my emphasis on "some" was elaborated in the rest of
  > what I said,

I'm sure it was.  But I'm talking about the attack (against Robert)
that I perceived in the first line.  Not about the substantive point
it was the start of.

-- 
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: Emacs Survey: Toolbars

[Drew Adams]

> I read these words
> 
>  > Nothing, except that people have been conditioned to expect that
>  > changes in options get saved automatically,
>  I assume you mean _some_ people.
> 
> and saw that things were getting snarky.  "I assume you mean" is a
> snarky way of disagreeing if it isn't reporting a typing error.

No, it's not.  It's not inherently any such thing.

It, and pretty much anything, _can_ be used to be
snarky.  And pretty much anything can be interpreted
to be snarky, if that's what one looks for or tends
to hear.

You may have "seen" things getting snarky, but
things were not snarky or getting snarky.  The
discussion was only technical, not personal,
until your intervention.

Would you have preferred that I write "I guess"
instead of "I assume"?  Or "Yes, some people have
been so conditioned, and ..."?  Or "Did you mean
to write '_some_ people'"?  If so, please consider
hearing some such phraseology.

My guess is that you may have been looking for
trouble, and so found it.  You may not think so.
And I may be wrong, of course - just a guess.
But maybe think about it.

I think/hope that if you reread all that was
written you'll see that nothing snarky was
intended, and there was no dispute - not even
a technical disagreement, AFAIK.

Qualifying the statement to only some people in
that context was no different from qualifying a
statement about integers to only natnums.  The
goal was clarification.  My point was that Emacs
can cater to more than one expected or preferred
alternative behavior.  Different strokes for
different folks.  Emacs shines at that.

> So I said,
> 
>   Would each you please take a deep breath, and respond
>   more kindly from now on?
> 
> I guess you took that as an attack, rather than as an exhortation,
> because you responded by throwing that perceived attack back at me:

An attack was perceived by you (3rd? 4th?).  It
wasn't an attack.  It was suggesting the same thing
you suggested, as a reply to what I sensed was an
overreaction to, and misinterpretation of, the
conversation and intentions, which were entirely
cooperative.

You advised us to take a deep breath, to step back
from a perceived dispute or snarkiness.  I asked
that you take a deep breath, to step back from an
overreaction.

>   Would you please take a deep breath?
> 
> I did as you suggested, and on second reading I agree
> that Robert Pluim's words were not unkind.  They seemed
> that way when I first read them.  Sorry, Robert.

I was hoping that a deep breath and rereading would
help you see there was no fight to break up, and no
malevolence.

Are you now hinting that only my words were unkind?
I might say I'm guessing that, but I prefer to give
you the benefit of the doubt.  And I'm glad you've
absolved Robert, at least.

> You continued with
> 
>   I don't think there was anything unkind in
>   either what Robert said or in my reply to him.
>   Did you actually read what each of us said?
> 
> Of course.  But only the parts that I cited.
> 
> I didn't read the whole messages, or any of the whole messages in that
> subthread, because I'm not participating in discussing that particular
> question.

We were interested in the question, even if you were
not.  It kind of feels like you weighed in as a
referee of sorts in what you thought was a personal
dispute.  A referee really owes it to all to follow
the action before judging.  Not doing so isn't fair.

> If I wanted to participate, I'd have to read the
> points made about it.  I decided it was easier
> just to say nothing about it.

That was what I guessed might have been the case.  It
can be easy (for anyone) to misinterpret something out
of context.  And then reacting to that can easily be
unfair.  Context is important.

> > The point of my emphasis on "some" was elaborated
> > in the rest of what I said,
> 
> I'm sure it was.  But I'm talking about the attack (against Robert)
> that I perceived in the first line.  Not about the substantive point
> it was the start of.

I hope I've made it clear now, and that by rereading
you'll understand there was no attack anywhere.

Along with deep breaths, please allow me to suggest /
prescribe (all) giving each other the _benefit of the
doubt_.  That can often go a long way toward avoiding
negative misunderstanding.

___

 Half of the people can be part right all of the time,
 Some of the people can be all right part of the time.
 But all the people can't be all right all the time
 I think Abraham Lincoln said that.
 "I'll let you be in my dreams if I can be in yours,"
 I said that.

   - R. Zimmerman

Re: Emacs Survey: Toolbars

[Alfred M. Szmidt]

Arguing back and forth who was or wasn't snarky isn't useful, it is
simpler and far more productive to simply say sorry if it came out
that way, no matter if it was ones fault or not and move on.

So instead of assuming that someone is trying to cause a bar fight at
every turn, lets assume that people are doing their best?  Right now
this is escalting based based on someone having percieved something as
unkind or an attack, instead of just accepting that they at the time
read it as such -- for whatever reason, and moving forward.

Re: Emacs Survey: Toolbars

[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's wrong with Options->Save Options?

  > Nothing, except that people have been conditioned to expect that
  > changes in options get saved automatically, so we could do that for
  > them if they make the changes via the menus.

That idea sounds good to me.  Or maybe ask the user whether to save the
change when the user requests a change.

Or offer buttons "Apply permanently" and "Apply for this session".

-- 
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: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>>> And perhaps there should be some menu to toggle the tool bar/scroll bars
>>> on/off?  That might be there already somewhere, but not in the menu
>>> where it would make sense -- the Options menu...
>>
>> It's under Options->Show/Hide.

In this UX experiment, this user was unable to find that option.  More
data!

But all kidding aside, that's a pretty baroque menu system there, and
putting the options for where the toolbar should be (!) in the same
place is just odd.

> Should we take this opportunity to either auto-save config changes
> made via the menus, or put a big red button somewhere saying 'click
> here to save settings', or prompt the user to save them when exiting?

Yes.

> (Iʼve never really liked the toolbar enable/disable menu. How many gui
> applications these days let you put the toolbar anywhere other than at
> the top?)

Yeah, that's weird, and shouldn't be in the menu.  It's a detail best
left to `M-x customize'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 17 Dec 2020 12:01:57 +0100
> 
> > (Iʼve never really liked the toolbar enable/disable menu. How many gui
> > applications these days let you put the toolbar anywhere other than at
> > the top?)
> 
> Yeah, that's weird, and shouldn't be in the menu.  It's a detail best
> left to `M-x customize'.

Took me a few moments to understand what you two are talking about.
You are both looking at a GTK build, right?  Where we allow the user
to control this aspect of the tool bar because GTK supports it?
AFAIK, no other toolkit has that menu item.

So if you want to ask what kind of GUI environment lets users put the
tool bar anywhere but the top, the answer is GTK ;-)

Re: Emacs Survey: Toolbars

[Dmitry Gutov]

On 15.12.2020 07:30, Lars Ingebrigtsen wrote:
> Of 7.3K respondents, 5K disable toolbars, which is more than two
> thirds.  So perhaps toolbars should default to off?  I know toolbars
> were all the rage in the 90s, but that's apparently not the case now.
> 
> Opinions?

I also think the poll is heavily biased in favor of either Reddit users 
(who are largely either power-users, or those who inspire to be), or 
experienced Emacs users in general.

For vast majority of them, disabling the toolbar is a trivial task. The 
ones who it really serves are less experienced users, non-programmers, 
etc. I don't think we have any significant data on that segment.

Furthermore, features like this can have a very strong survivor bias: if 
the toolbars are bad, users will disable them. But a better answer would 
be to improve them instead.

Rather than one poll, it might be worth more to look at similar programs 
(VS Code and IntelliJ IDEA come to mind) which both have a toolbar by 
default, but make it easy enough to disable the "distracting" elements 
of the UI for those who prefer them off.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 10:07 PM
> From: "Dmitry Gutov" <dgutov@yandex.ru>
> To: "Lars Ingebrigtsen" <larsi@gnus.org>, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> On 15.12.2020 07:30, Lars Ingebrigtsen wrote:
> > Of 7.3K respondents, 5K disable toolbars, which is more than two
> > thirds.  So perhaps toolbars should default to off?  I know toolbars
> > were all the rage in the 90s, but that's apparently not the case now.
> >
> > Opinions?
>
> I also think the poll is heavily biased in favor of either Reddit users
> (who are largely either power-users, or those who inspire to be), or
> experienced Emacs users in general.
>
> For vast majority of them, disabling the toolbar is a trivial task. The
> ones who it really serves are less experienced users, non-programmers,
> etc. I don't think we have any significant data on that segment.
>
> Furthermore, features like this can have a very strong survivor bias: if
> the toolbars are bad, users will disable them. But a better answer would
> be to improve them instead.

Spot on.  There are aspects where certain modes are unwanted because they are not
feature complete.  Have found too many instances of lost opportunities in industry
where projects are forgotten in that way.

> Rather than one poll, it might be worth more to look at similar programs
> (VS Code and IntelliJ IDEA come to mind) which both have a toolbar by
> default, but make it easy enough to disable the "distracting" elements
> of the UI for those who prefer them off.
>
>

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I also think the poll is heavily biased in favor of either Reddit
> users (who are largely either power-users, or those who inspire to
> be), or experienced Emacs users in general.

My impression is that that's not accurate -- there's certainly
experienced people who hang out on the Emacs Reddit group, but there's
also a lot of new users.  (And my guess is that the latter group is
larger, based on the questions I see asked there.)

In the mega-thread about modernising Emacs, the common refrain was that
we needed actual data on what users do.  We now have some data, and I
don't think we should just dismiss that data because of statistical
quibbles.

And the data says that, at present, the Emacs toolbars are not very
useful.  Stefan's point about improving the toolbars so that they become
useful is good, but I'm not sure that's realistic: We've had these
toolbars for decades, and not much has happened with them.  (Except
growing progressively smaller.)

I mean, look at the toolbar that happens when you "emacs -Q": You get an
Emacs with a scratch buffer...  with a "Save" icon.  In a buffer that
can't be saved.  That's how much attention we've spent on toolbars in
two decades.

All the items in the *scratch* buffer toolbar are more natural for a
menu, and they're already present there.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> We now have some data, and I don't think we should just dismiss that
> data because of statistical quibbles.

Speaking of statistics -- I found Dick Mao's analysis of the survey
pretty interesting:

https://github.com/dickmao/emacs-survey/blob/main/2020/commentary.ipynb

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Christopher Dimech]

It is evident how a lot of the reasoning is flawed!  Making something harder than it needs to be
is good.  Only Conmen complicate things more than they should be.  And only a genius simplifies
complicated things.

One of the most surprising aspects of this study is how often programmers have been proved not only
wrong, but grossly and disastrously wrong in their prescriptions for the ills of society -- and how
little their views have changed in response to empirical evidence of the disasters entailed by those
views.

Emacs core contributors is and probably should remain small
===========================================================

Making something harder than it needs to be does ensure a certain competence. Manual transmission cars
are another example of such natural gatekeeping. You were more assured of a new driver's roadworthiness
if she could work a clutch, more so than if she relied on electronic assists to parallel park.


---------------------
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy


> Sent: Wednesday, December 16, 2020 at 10:28 AM
> From: "Lars Ingebrigtsen" <larsi@gnus.org>
> To: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > We now have some data, and I don't think we should just dismiss that
> > data because of statistical quibbles.
>
> Speaking of statistics -- I found Dick Mao's analysis of the survey
> pretty interesting:
>
> https://github.com/dickmao/emacs-survey/blob/main/2020/commentary.ipynb
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>

Re: Emacs Survey: Toolbars

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

  > Speaking of statistics -- I found Dick Mao's analysis of the survey
  > pretty interesting:

  > https://github.com/dickmao/emacs-survey/blob/main/2020/commentary.ipynb

I fetched that URL but all I saw were some GitHub command buttons and links.
Where can I find the actual information?

I have never used GitHub.
-- 
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: Emacs Survey: Toolbars

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > Speaking of statistics -- I found Dick Mao's analysis of the survey
>   > pretty interesting:
>
>   > https://github.com/dickmao/emacs-survey/blob/main/2020/commentary.ipynb
>
> I fetched that URL but all I saw were some GitHub command buttons and links.
> Where can I find the actual information?
>
> I have never used GitHub.

I think you can just run

git clone https://github.com/dickmao/emacs-survey

Best,
Ihor

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>   > Speaking of statistics -- I found Dick Mao's analysis of the survey
>   > pretty interesting:
>
>   > https://github.com/dickmao/emacs-survey/blob/main/2020/commentary.ipynb
>
> I fetched that URL but all I saw were some GitHub command buttons and links.
> Where can I find the actual information?

The page has a bunch of charts and graphs, but you have to enable
Javascript to see them.  (And, no, the Javascript isn't free.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[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 page has a bunch of charts and graphs, but you have to enable
  > Javascript to see them.  (And, no, the Javascript isn't free.)

That is not a good state of affairs.  Would someone who is skilled at
interpersonal relationships like to ask him politely to make that JS
code free, or convert the information to a directly readable format
and post that, or some other adequate solution?

-- 
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: Emacs Survey: Toolbars

[Daniel Brooks]

Richard Stallman <rms@gnu.org> writes:

>   > The page has a bunch of charts and graphs, but you have to enable
>   > Javascript to see them.  (And, no, the Javascript isn't free.)
>
> That is not a good state of affairs.  Would someone who is skilled at
> interpersonal relationships like to ask him politely to make that JS
> code free, or convert the information to a directly readable format
> and post that, or some other adequate solution?

You can view it locally using Jupyter Notebook, which is a bit like
Maxima or Macsyma but with Python instead of Lisp, and uses the Modified
BSD license.

On my Fedora machine I installed it with "dnf install python3-notebook",
then run Jupyter with "jupyter notebook commentary.ipynb". It took me a
while to find the right package name, because it doesn't have the name
"Jupyter" in either the name or the short description; an odd choice.

db48x

Re: Emacs Survey: Toolbars

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

  > You can view it locally using Jupyter Notebook, which is a bit like
  > Maxima or Macsyma but with Python instead of Lisp, and uses the Modified
  > BSD license.

That might be a solution I pesonally could use -- if I understood how
to do it -- but there is more at stake than my seeing those graphs.
Much more.
It is not a good state of affairs for this information to direct people
to run a nonfree program, and worse yet, that it happens in connection
with Emacs.

Would someone who is skilled at
interpersonal relationships like to ask Dick Mao politely to make that JS
code free, or convert the information to a directly readable format
> and post that, or delete the JS and give a recipe for viewing the
graphs using Jupyter Notebook, or some other adequate solution?


-- 
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: Emacs Survey: Toolbars

[Daniel Brooks]

Richard Stallman <rms@gnu.org> writes:

>   > You can view it locally using Jupyter Notebook, which is a bit like
>   > Maxima or Macsyma but with Python instead of Lisp, and uses the Modified
>   > BSD license.
>
> That might be a solution I pesonally could use -- if I understood how
> to do it -- but there is more at stake than my seeing those graphs.
> Much more.
> It is not a good state of affairs for this information to direct people
> to run a nonfree program, and worse yet, that it happens in connection
> with Emacs.
>
> Would someone who is skilled at
> interpersonal relationships like to ask Dick Mao politely to make that JS
> code free, or convert the information to a directly readable format
>> and post that, or delete the JS and give a recipe for viewing the
> graphs using Jupyter Notebook, or some other adequate solution?

There's no JS for any of us to delete or to make free. GitHub renders
the notebook using the same Jupyter Notebook software that I recommend
using to view it with, so that's not a problem. It's just GitHub's own
JS that isn't free software.

Of course the graphs could be published anywhere else as well. Well, I
assume that it's not difficult to get Jupyter Notebook to export a
static view of the document, since GitHub does that already… Yea, in the
Jupyter interface, select File → Download As… → HTML. That opens it in a
new tab of your browser, and then you can use your browser to save it to
disk.

That said, I suspect that the notebook is just an intermediate
representation. There's also a notebook in the repository called "Emacs
User Survey 2020.ipynb" which was obviously used to generate the graphs
on the official survey results webpage: https://emacssurvey.org/2020/

I don't know if there's a plan to publish Dick Mao's commentary.ipynb
the same way, but it could obviously be done the same way.

db48x

Re: Emacs Survey: Toolbars

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

  > Of course the graphs could be published anywhere else as well.

Yes.  Would someone like to ask Dick Mao to do that?

  > Yea, in the
  > Jupyter interface, select File → Download As… → HTML.

I know you're trying to help me look at it, but these are terse
instructions for a program I have never seen.  To try to run it
would imply a lot of time futzing around.  It would mean losing time
I should use for other pending tasks.

Anyway, Caio sent me am image file which shows the results.
So I personally don't need help any more.

But it's still a bad thing to have this posted in a way that tends to
lead people to run nonfree software.  Let's aim to _fix_ the problem
rather than work around 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: Re: Emacs Survey: Toolbars

[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 is not a good state of affairs.  Would someone who is skilled at
  > > interpersonal relationships like to ask him politely to make that JS
  > > code free, or convert the information to a directly readable format
  > > and post that, or some other adequate solution?

  > Attached to this email is a png image of that website.

Thanks, I will look.  But that helps only me.  The situation
is still not a good state of affairs, so we could still use
someone to contact Dick Mao.

-- 
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: Emacs Survey: Toolbars

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

Thank you.  It is interesting.

One thing I noticed is that there seem to be difficulties in GUD
(debugging under Emacs).  That is a gad situation.  Can we encourage
users to report the problems, and devote effort to debugging them?

-- 
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: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 21 Dec 2020 00:53:16 -0500
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> One thing I noticed is that there seem to be difficulties in GUD
> (debugging under Emacs).  That is a bad situation.  Can we encourage
> users to report the problems, and devote effort to debugging them?

I didn't interpret what he wrote to mean there's a problem.  I
interpreted it to mean he personally stopped using the Emacs GDB front
end long ago.  So he doesn't really say anything about gdb-mi.el, the
current GDB front end in Emacs.

Re: Emacs Survey: Toolbars

[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 didn't interpret what he wrote to mean there's a problem.  I
  > interpreted it to mean he personally stopped using the Emacs GDB front
  > end long ago.  So he doesn't really say anything about gdb-mi.el, the
  > current GDB front end in Emacs.

I am not sure what he meant, but he seems to claim, in a vague way,
that it has had problems over the years.  This might refer to real
problems.  In case that is so, we should ask for details.

Would someone be willing to ask him to tell us what he meant,
and where we could look for specifics?

Of course, the users should have sent bug reports, but since they didn't,
let's try to find out what the bugs are.


-- 
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: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: larsi@gnus.org, caiohcs0@gmail.com, emacs-devel@gnu.org
> Date: Tue, 22 Dec 2020 00:20:34 -0500
> 
>   > I didn't interpret what he wrote to mean there's a problem.  I
>   > interpreted it to mean he personally stopped using the Emacs GDB front
>   > end long ago.  So he doesn't really say anything about gdb-mi.el, the
>   > current GDB front end in Emacs.
> 
> I am not sure what he meant, but he seems to claim, in a vague way,
> that it has had problems over the years.  This might refer to real
> problems.  In case that is so, we should ask for details.

He said that about gud.el, which is nowadays obsolete, as far as its
GDB interface is concerned.  We leave its GDB parts in Emacs only
because in some rare cases using annotations works better with GDB
than using the MI interface.

Re: Emacs Survey: Toolbars

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

  > He said that about gud.el, which is nowadays obsolete, as far as its
  > GDB interface is concerned.  We leave its GDB parts in Emacs only
  > because in some rare cases using annotations works better with GDB
  > than using the MI interface.

His meaning was not clear to me.  If there is no reason to think
there is a problem in that area now, that's great.

-- 
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: Emacs Survey: Toolbars

[Andy Moreton]

On Mon 21 Dec 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. ]]]
>
> Thank you.  It is interesting.
>
> One thing I noticed is that there seem to be difficulties in GUD
> (debugging under Emacs).  That is a gad situation.  Can we encourage
> users to report the problems, and devote effort to debugging them?

Can you please quote the relevant part of the message you are replying
to ? It is jarring to read a message without any context. That is a
discourtesy to readers, who must work harder to find which part of a
message you are replying to (and some client software makes that harder
by not threading messages properly).

    AndyM

Re: Emacs Survey: Toolbars

[Caio Henrique]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Mon 21 Dec 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. ]]]
>>
>> Thank you.  It is interesting.
>>
>> One thing I noticed is that there seem to be difficulties in GUD
>> (debugging under Emacs).  That is a gad situation.  Can we encourage
>> users to report the problems, and devote effort to debugging them?
>
> Can you please quote the relevant part of the message you are replying
> to ? It is jarring to read a message without any context. That is a
> discourtesy to readers, who must work harder to find which part of a
> message you are replying to (and some client software makes that harder
> by not threading messages properly).
>
>     AndyM

I think that he is replying to this part of dickmao's survey commentary:

> Gdb in emacs used to be so nice
>Time was M-x gdb worked flawlessly. At some point, gud or "Grand Unified
>Debugger" became the ring to rule them all, with no discernible loss of
>functionality. Then some time in the oughts, things started to go
>sideways, and "realgud" attempted to make debugging great again with
>limited success. Now the latest pretender to the throne is something
>called gdb/mi, with a flashy upstart called "dap-mode" nipping at its
>mud-caked heels, but at this point I'm too accustomed to running gdb
>outside emacs. 

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 16 Dec 2020 10:24:07 +0100
> Cc: emacs-devel@gnu.org
> 
> I mean, look at the toolbar that happens when you "emacs -Q": You get an
> Emacs with a scratch buffer...  with a "Save" icon.  In a buffer that
> can't be saved.

Which is why the "Save" button is disabled when you are in *scratch*.

> That's how much attention we've spent on toolbars in two decades.

I think we gave the tool bar (and the menu bar) attention it deserves.

> All the items in the *scratch* buffer toolbar are more natural for a
> menu, and they're already present there.

That is generally true for any tool bar in any GUI program.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

---------------------
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy


> Sent: Wednesday, December 16, 2020 at 5:03 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Lars Ingebrigtsen" <larsi@gnus.org>
> Cc: emacs-devel@gnu.org, dgutov@yandex.ru
> Subject: Re: Emacs Survey: Toolbars
>
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Wed, 16 Dec 2020 10:24:07 +0100
> > Cc: emacs-devel@gnu.org
> >
> > I mean, look at the toolbar that happens when you "emacs -Q": You get an
> > Emacs with a scratch buffer...  with a "Save" icon.  In a buffer that
> > can't be saved.
>
> Which is why the "Save" button is disabled when you are in *scratch*.
>
> > That's how much attention we've spent on toolbars in two decades.
>
> I think we gave the tool bar (and the menu bar) attention it deserves.

There are more important areas for improvement than whether a switch is "on" or "off".
For instance, making auto-complete be part of standard emacs by default, extending the
completion interface to provide an environment for users to concentrate more on their
own work.

Emacs got momentum in the past because of great tools like org-mode, magit, ivy.

> > All the items in the *scratch* buffer toolbar are more natural for a
> > menu, and they're already present there.
>
> That is generally true for any tool bar in any GUI program.
>
>

Re: Emacs Survey: Toolbars

[Dmitry Gutov]

On 16.12.2020 11:24, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> I also think the poll is heavily biased in favor of either Reddit
>> users (who are largely either power-users, or those who inspire to
>> be), or experienced Emacs users in general.
> 
> My impression is that that's not accurate -- there's certainly
> experienced people who hang out on the Emacs Reddit group, but there's
> also a lot of new users.  (And my guess is that the latter group is
> larger, based on the questions I see asked there.)

New users ask questions more often than the more experienced ones. There 
are 50K subscribers to r/emacs and 300 people online just now. Clearly, 
people asking questions are a minority.

> In the mega-thread about modernising Emacs, the common refrain was that
> we needed actual data on what users do.  We now have some data, and I
> don't think we should just dismiss that data because of statistical
> quibbles.

The question is how to contextualize the data and what to do about it.

I agree that the toolbars we have are probably less useful than they 
could be.

> I mean, look at the toolbar that happens when you "emacs -Q": You get an
> Emacs with a scratch buffer...  with a "Save" icon.  In a buffer that
> can't be saved.  That's how much attention we've spent on toolbars in
> two decades.

Well, it actually can be saved, as soon as you type something (C-x C-s 
works), and it's one of the real usage patterns. The button doesn't 
indicate that, though.

But OTOH we have other buttons (New file, Open, Undo, Cut and Paste) 
that a lot of users expect from a text editor.

> All the items in the *scratch* buffer toolbar are more natural for a
> menu, and they're already present there.

Maybe you're right. I checked back, and most contemporary text editors 
don't have a toolbar like we do.

Atom/Sublime/VS Code don't have this kind of editor toolbar. IDEA only 
has specialized toolbars for, like, debugging.

The recent versions of Kate (KDE editor) also seem to have removed it. 
GNOME Builder only has a small number of buttons, and they are on the 
title bar. Geany still has a toolbar, though.

Even MS Word, while it has a toolbar for certain features, has moved the 
basic edit buttons to the window titlebar and made them pretty small.

Re: Emacs Survey: Toolbars

[John Yates]

On Wed, Dec 16, 2020 at 12:20 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> But OTOH we have other buttons (New file, Open, Undo, Cut and Paste)
> that a lot of users expect from a text editor.

My sense is that such buttons made sense when a smaller fraction of the
population was computer literate.  These days I would expect them only
on the most simplistic of editors, those still addressing absolute beginners.

Folk using more featureful editors (emacs or otherwise) can be assumed
to have already mastered some of the fundamentals of editing text.  Put
another way, can we not assume that anyone, even those using emacs
for the very first time, has some notion of key bindings (even if those are
C-c, C-x and C-v) and expects New, Open, Save, SaveAs and Close on
a File menu?

/john

RE: Emacs Survey: Toolbars

[Drew Adams]

> My sense is that such buttons made sense when a smaller fraction of the
> population was computer literate.  These days I would expect them only
> on the most simplistic of editors, those still addressing absolute beginners.
> 
> Folk using more featureful editors (emacs or otherwise) can be assumed
> to have already mastered some of the fundamentals of editing text.  Put
> another way, can we not assume that anyone, even those using emacs
> for the very first time, has some notion of key bindings (even if those are
> C-c, C-x and C-v) and expects New, Open, Save, SaveAs and Close on
> a File menu?

Actually, there are a fair number of GUI applications
that pretty much require a lot of mouse clicking - no
easy way to use the keyboard for many things.

And of those there are a fair number that have lots
of toolbar buttons/icons.  And in such contexts it
can sometimes be quicker to click such a button than
to access the equivalent menu item, which might be
nested (whether from the menu bar or a popup menu).

Such things don't apply to Emacs, in the sense that
you're not _required_ to use menus or a toolbar.  But
their existence elsewhere might be an argument for
Emacs supporting them.

Re: RE: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Wednesday, December 16, 2020 at 9:29 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "John Yates" <john@yates-sheets.org>, "Dmitry Gutov" <dgutov@yandex.ru>
> Cc: "Lars Ingebrigtsen" <larsi@gnus.org>, "Emacs developers" <emacs-devel@gnu.org>
> Subject: RE: Emacs Survey: Toolbars
>
> > My sense is that such buttons made sense when a smaller fraction of the
> > population was computer literate.  These days I would expect them only
> > on the most simplistic of editors, those still addressing absolute beginners.
> >
> > Folk using more featureful editors (emacs or otherwise) can be assumed
> > to have already mastered some of the fundamentals of editing text.  Put
> > another way, can we not assume that anyone, even those using emacs
> > for the very first time, has some notion of key bindings (even if those are
> > C-c, C-x and C-v) and expects New, Open, Save, SaveAs and Close on
> > a File menu?
>
> Actually, there are a fair number of GUI applications
> that pretty much require a lot of mouse clicking - no
> easy way to use the keyboard for many things.
>
> And of those there are a fair number that have lots
> of toolbar buttons/icons.  And in such contexts it
> can sometimes be quicker to click such a button than
> to access the equivalent menu item, which might be
> nested (whether from the menu bar or a popup menu).

Absolutely correct.  But many fail to properly realise that.

> Such things don't apply to Emacs, in the sense that
> you're not _required_ to use menus or a toolbar.  But
> their existence elsewhere might be an argument for
> Emacs supporting them.

It is on the opposite side of the spectrum.  If the trend in this discussion
continues, Emacs will be forcing you to use keybindings, no other option.
That is a regression.  Emacs must provide flexibilityon both aspects.  Or at
least the functionality to do so by writing some elisp.

Re: Emacs Survey: Toolbars

[chad]

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

On Wed, Dec 16, 2020 at 12:12 PM John Yates <john@yates-sheets.org> wrote:

> On Wed, Dec 16, 2020 at 12:20 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> > But OTOH we have other buttons (New file, Open, Undo, Cut and Paste)
> > that a lot of users expect from a text editor.
>
> My sense is that such buttons made sense when a smaller fraction of the
> population was computer literate.  These days I would expect them only
> on the most simplistic of editors, those still addressing absolute
> beginners.
>

I think this expectation is solid, but there's a wrinkle: If the toolbar is
largely aimed at helping new users make use of emacs, then having an
obvious way to do common functionality that _doesn't use the common
bindings_ seems like a good use of toolbar space. Now that the buttons
advertise the emacs bindings for these functions in a new-user-friendly
way, they're potentially even more helpful, since they both provide a clear
way to save/cut/copy/paste/undo, and they also teach the default emacs
bindings for same.

To this end, I'd suggest adding a button to the default toolbar that
launches a short tutorial (in a new frame on gui systems), that talks about
these common actions/bindings, with a next-step link describing why emacs
uses these bindings and how to change them. It should also have an option
to remove the tutorial-launching button from the toolbar.

I can probably put together a prototype of this if people would like, and I
recall some pieces of similar ideas floating around emacs-devel in the past
6-8 months. Would this be interesting to people?

~Chad

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

Re: Emacs Survey: Toolbars

[Christopher Dimech]

[-- Attachment #1: Type: text/html, Size: 3409 bytes --]

Re: Emacs Survey: Toolbars

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

  > --- Not fully correct.  Toolbars assist those who suffer from pain pressing
  > keys.

If you have trouble pressing keys, the toolbar will save you at most
a tiny fraction of the keys you need to press to enter some text.

-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

Dear Richard,

It is difficult to use a mouse clicking tool to perform the keysequence on a virtual
keyboard.  When using a mouse clicking tool with a virtual keyboard, the number of
presses that are saved, stop being a tiny fraction.  It is then the keybinding approach
that gets in the way.

Regards
Christopher

> Sent: Friday, December 18, 2020 at 6:33 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: yandros@gmail.com, dgutov@yandex.ru, larsi@gnus.org, john@yates-sheets.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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. ]]]
>
>   > --- Not fully correct.  Toolbars assist those who suffer from pain pressing
>   > keys.
>
> If you have trouble pressing keys, the toolbar will save you at most
> a tiny fraction of the keys you need to press to enter some text.
>
> --
> 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: Emacs Survey: Toolbars

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-12-18 09:00]:
> Dear Richard,
> 
> It is difficult to use a mouse clicking tool to perform the
> keysequence on a virtual keyboard.  When using a mouse clicking tool
> with a virtual keyboard, the number of presses that are saved, stop
> being a tiny fraction.  It is then the keybinding approach that gets
> in the way.

To give you more insights from me as user, I do use toolbar, sometimes
not. In general it does not disturb me neither I see it. It is useful
as one level of accessible user interface. It offers similar to menu
items specific functions by only using the mouse and a click and that
is great.

Emacs with toolbar is on a level more accessible.

Toolbar is occupying only about one third of linear space on my screen
and in my opinion it should be full of functions such as:

- new frame
- bookmarks list
- text properties such as justification full, centering
- Emacs packages
- report emacs bug
- spell checking
- version control check in/out
- calendar
- calculator
- send email
- then help functions like About Emacs or manual

Including a rich toolbar makes options accessible more to users to
discover more useful features of Emacs.

Including more accessibility features would help that Emacs become
useful for more people.

Gestures would be another useful accessibility feature. But I think it
exists already, I just forgot is it a built-in package. Then user
could move mouse in some direction as specified to launch some Emacs
commands. This would help on touch screen as well.

Accessibility on one level more would be speech recognition where user
activates it by saying "M-x" "find file" or "M-x" "mail" to activate
features.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Friday, December 18, 2020 at 9:43 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org, dgutov@yandex.ru, larsi@gnus.org, yandros@gmail.com, john@yates-sheets.org
> Subject: Re: Emacs Survey: Toolbars
>
> * Christopher Dimech <dimech@gmx.com> [2020-12-18 09:00]:
> > Dear Richard,
> >
> > It is difficult to use a mouse clicking tool to perform the
> > keysequence on a virtual keyboard.  When using a mouse clicking tool
> > with a virtual keyboard, the number of presses that are saved, stop
> > being a tiny fraction.  It is then the keybinding approach that gets
> > in the way.
>
> To give you more insights from me as user, I do use toolbar, sometimes
> not. In general it does not disturb me neither I see it. It is useful
> as one level of accessible user interface. It offers similar to menu
> items specific functions by only using the mouse and a click and that
> is great.
>
> Emacs with toolbar is on a level more accessible.
>
> Toolbar is occupying only about one third of linear space on my screen
> and in my opinion it should be full of functions such as:
>
> - new frame
> - bookmarks list
> - text properties such as justification full, centering
> - Emacs packages
> - report emacs bug
> - spell checking
> - version control check in/out
> - calendar
> - calculator
> - send email
> - then help functions like About Emacs or manual
>
> Including a rich toolbar makes options accessible more to users to
> discover more useful features of Emacs.
>
> Including more accessibility features would help that Emacs become
> useful for more people.

Have suggested that the toolbar items could be user defined as it is
for keybindings.

> Gestures would be another useful accessibility feature. But I think it
> exists already, I just forgot is it a built-in package. Then user
> could move mouse in some direction as specified to launch some Emacs
> commands. This would help on touch screen as well.
>
> Accessibility on one level more would be speech recognition where user
> activates it by saying "M-x" "find file" or "M-x" "mail" to activate
> features.
>
>
>
>

Re: Emacs Survey: Toolbars

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-12-18 11:54]:
> > Including more accessibility features would help that Emacs become
> > useful for more people.
> 
> Have suggested that the toolbar items could be user defined as it is
> for keybindings.

Toolbar is offering accessibility feature that some functions may be
chosen with the mouse.

Itself it is easily customizable.

But offering toolbar to be customizable such as in defcustom style
would not be accessible by users, it would be redundant as programmers
can already customize it.

What would be accessible is to provide icons for many functions and
let users drag and drop into the toolbar.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Friday, December 18, 2020 at 11:04 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org, dgutov@yandex.ru, larsi@gnus.org, yandros@gmail.com, john@yates-sheets.org
> Subject: Re: Emacs Survey: Toolbars
>
> * Christopher Dimech <dimech@gmx.com> [2020-12-18 11:54]:
> > > Including more accessibility features would help that Emacs become
> > > useful for more people.
> >
> > Have suggested that the toolbar items could be user defined as it is
> > for keybindings.
>
> Toolbar is offering accessibility feature that some functions may be
> chosen with the mouse.
>
> Itself it is easily customizable.
>
> But offering toolbar to be customizable such as in defcustom style
> would not be accessible by users, it would be redundant as programmers
> can already customize it.
>
> What would be accessible is to provide icons for many functions and
> let users drag and drop into the toolbar.

Correct, that what I mean.  But also that a toolbar icon could run a user
defined function.

My disagreement with Lars is that he wants that the determination of when the toolbar
can be used is defined by what makes sense to the maintainers of Emacs.

Completely wrong.

>

RE: Emacs Survey: Toolbars

[Drew Adams]

> > What would be accessible is to provide icons for many functions and
> > let users drag and drop into the toolbar.
> 
> Correct, that what I mean.  But also that a toolbar icon could run a user
> defined function.
> 
> My disagreement with Lars is that he wants that the determination of when the
> toolbar can be used is defined by what makes sense to the maintainers of Emacs.
> 
> Completely wrong.

A very easy start would be to provide a single button
that is shown only if it has an associated binding/action,
and whose action is user-defined, the value of a user
option.

No, that doesn't respond to all that you request (which
I support, BTW).  But it would seem like a zero-cost
no-brainer, to at least let user get a user-defined
toolbar button.  And the action option could be buffer
local.  You'd at least get a user-definable,
mode-specific button.

Re: Emacs Survey: Toolbars

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-12-18 21:07]:
> > > What would be accessible is to provide icons for many functions and
> > > let users drag and drop into the toolbar.
> > 
> > Correct, that what I mean.  But also that a toolbar icon could run a user
> > defined function.
> > 
> > My disagreement with Lars is that he wants that the determination of when the
> > toolbar can be used is defined by what makes sense to the maintainers of Emacs.
> > 
> > Completely wrong.
> 
> A very easy start would be to provide a single button
> that is shown only if it has an associated binding/action,
> and whose action is user-defined, the value of a user
> option.

Package that could send anonymous statistics would be useful to find
out what and how people really and and do.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Friday, December 18, 2020 at 11:04 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org, dgutov@yandex.ru, larsi@gnus.org, yandros@gmail.com, john@yates-sheets.org
> Subject: Re: Emacs Survey: Toolbars
>
> * Christopher Dimech <dimech@gmx.com> [2020-12-18 11:54]:
> > > Including more accessibility features would help that Emacs become
> > > useful for more people.
> >
> > Have suggested that the toolbar items could be user defined as it is
> > for keybindings.
>
> Toolbar is offering accessibility feature that some functions may be
> chosen with the mouse.
>
> Itself it is easily customizable.
>
> But offering toolbar to be customizable such as in defcustom style
> would not be accessible by users, it would be redundant as programmers
> can already customize it.
>
> What would be accessible is to provide icons for many functions and
> let users drag and drop into the toolbar.

The toolbar can be detached like in Gimp when enabled.

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> I mean, look at the toolbar that happens when you "emacs -Q": You get an
>> Emacs with a scratch buffer...  with a "Save" icon.  In a buffer that
>> can't be saved.  That's how much attention we've spent on toolbars in
>> two decades.
>
> Well, it actually can be saved, as soon as you type something (C-x C-s
> works), and it's one of the real usage patterns. The button doesn't
> indicate that, though.

Yeah, the save button stays grayed out and you can't click it, which I
take to be an indication that this toolbar hasn't gotten a lot of love.
I mean, it's the toolbar shown in "emacs -Q", and even that one is
pretty nonsensical.

> Maybe you're right. I checked back, and most contemporary text editors
> don't have a toolbar like we do.
>
> Atom/Sublime/VS Code don't have this kind of editor toolbar. IDEA only
> has specialized toolbars for, like, debugging.
>
> The recent versions of Kate (KDE editor) also seem to have removed
> it. GNOME Builder only has a small number of buttons, and they are on
> the title bar. Geany still has a toolbar, though.
>
> Even MS Word, while it has a toolbar for certain features, has moved
> the basic edit buttons to the window titlebar and made them pretty
> small.

I think we should consider setting some standards for what should be in
a toolbar, and normal editing commands shouldn't be there.  That is, a
toolbar should be for things that people want to click a lot, like
"pause" in a media player, or navigation commands like "prev/next" in
*Help*.

I just had a peek at the toolbar in *Help* -- it includes things like
"Save" and "Undo".  No wonder most people disable the thing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Thursday, December 17, 2020 at 11:58 AM
> From: "Lars Ingebrigtsen" <larsi@gnus.org>
> To: "Dmitry Gutov" <dgutov@yandex.ru>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> >> I mean, look at the toolbar that happens when you "emacs -Q": You get an
> >> Emacs with a scratch buffer...  with a "Save" icon.  In a buffer that
> >> can't be saved.  That's how much attention we've spent on toolbars in
> >> two decades.

> > Well, it actually can be saved, as soon as you type something (C-x C-s
> > works), and it's one of the real usage patterns. The button doesn't
> > indicate that, though.
>
> Yeah, the save button stays grayed out and you can't click it, which I
> take to be an indication that this toolbar hasn't gotten a lot of love.
> I mean, it's the toolbar shown in "emacs -Q", and even that one is
> pretty nonsensical.
>
> > Maybe you're right. I checked back, and most contemporary text editors
> > don't have a toolbar like we do.
> >
> > Atom/Sublime/VS Code don't have this kind of editor toolbar. IDEA only
> > has specialized toolbars for, like, debugging.
> >
> > The recent versions of Kate (KDE editor) also seem to have removed
> > it. GNOME Builder only has a small number of buttons, and they are on
> > the title bar. Geany still has a toolbar, though.
> >
> > Even MS Word, while it has a toolbar for certain features, has moved
> > the basic edit buttons to the window titlebar and made them pretty
> > small.
>
> I think we should consider setting some standards for what should be in
> a toolbar, and normal editing commands shouldn't be there.  That is, a
> toolbar should be for things that people want to click a lot, like
> "pause" in a media player, or navigation commands like "prev/next" in
> *Help*.

It's the users who know what they want to click, so make them able to
introduce icons with the commands they want.  Someone has said there
already exists some of that functionality.  In my browser I can drag
whatever item I want to the toolbar!

Artists use toolbars all the time.  Gimp has a toolbar you can drag around.
Fantastic.  And Cad Systems rely on them.

> I just had a peek at the toolbar in *Help* -- it includes things like
> "Save" and "Undo".  No wonder most people disable the thing.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>

Re: Emacs Survey: Toolbars

[Dmitry Gutov]

On 17.12.2020 12:58, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>>> I mean, look at the toolbar that happens when you "emacs -Q": You get an
>>> Emacs with a scratch buffer...  with a "Save" icon.  In a buffer that
>>> can't be saved.  That's how much attention we've spent on toolbars in
>>> two decades.
>>
>> Well, it actually can be saved, as soon as you type something (C-x C-s
>> works), and it's one of the real usage patterns. The button doesn't
>> indicate that, though.
> 
> Yeah, the save button stays grayed out and you can't click it, which I
> take to be an indication that this toolbar hasn't gotten a lot of love.

It's not obvious how to fix it, though, because an active "save" button 
is like a reminder to save regularly, whereas saving the scratch is an 
explicit, advanced usage pattern.

> I mean, it's the toolbar shown in "emacs -Q", and even that one is
> pretty nonsensical.

I guess I was somewhat attached to the idea of it because it looks 
pretty and neat on my system (with -Q).

Definitely more so than the splash screen, the discussions about 
improving which have all seemingly fizzled out.

>> Maybe you're right. I checked back, and most contemporary text editors
>> don't have a toolbar like we do.
>>
>> Atom/Sublime/VS Code don't have this kind of editor toolbar. IDEA only
>> has specialized toolbars for, like, debugging.
>>
>> The recent versions of Kate (KDE editor) also seem to have removed
>> it. GNOME Builder only has a small number of buttons, and they are on
>> the title bar. Geany still has a toolbar, though.
>>
>> Even MS Word, while it has a toolbar for certain features, has moved
>> the basic edit buttons to the window titlebar and made them pretty
>> small.
> 
> I think we should consider setting some standards for what should be in
> a toolbar, and normal editing commands shouldn't be there.  That is, a
> toolbar should be for things that people want to click a lot, like
> "pause" in a media player, or navigation commands like "prev/next" in
> *Help*.

Yes, probably. And if there are not enough of such buttons that we can 
come up with, the toolbar should be hidden for that particular mode.

But... can it work well? Showing the toolbar in some modes yet hiding it 
in others? Jumping window heights are a known source of annoyance.

All the editors I mentioned above that do have toolbars have avoided 
this problem, some way or another.

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> But... can it work well? Showing the toolbar in some modes yet hiding
> it in others? Jumping window heights are a known source of annoyance.

Yes.  If we want to go in a toolbars-only-in-modes-where-it's-useful
direction, we'll have to fix the height annoyance.  Well, we should do
that anyway...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Thursday, December 17, 2020 at 1:12 PM
> From: "Lars Ingebrigtsen" <larsi@gnus.org>
> To: "Dmitry Gutov" <dgutov@yandex.ru>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > But... can it work well? Showing the toolbar in some modes yet hiding
> > it in others? Jumping window heights are a known source of annoyance.
>
> Yes.  If we want to go in a toolbars-only-in-modes-where-it's-useful
> direction, we'll have to fix the height annoyance.  Well, we should do
> that anyway...

It can be done as is done with Gimp, nobdy complains about a detached toolbar in Gimp.
I can be as Speedbar is.


> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 17 Dec 2020 11:58:35 +0100
> Cc: emacs-devel@gnu.org
> 
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> >> I mean, look at the toolbar that happens when you "emacs -Q": You get an
> >> Emacs with a scratch buffer...  with a "Save" icon.  In a buffer that
> >> can't be saved.  That's how much attention we've spent on toolbars in
> >> two decades.
> >
> > Well, it actually can be saved, as soon as you type something (C-x C-s
> > works), and it's one of the real usage patterns. The button doesn't
> > indicate that, though.
> 
> Yeah, the save button stays grayed out and you can't click it, which I
> take to be an indication that this toolbar hasn't gotten a lot of love.

??? I'd say it's the other way around: they are insensitive _because_
someone thought about avoiding to trip the user.

> I just had a peek at the toolbar in *Help* -- it includes things like
> "Save" and "Undo".  No wonder most people disable the thing.

I don't understand what you'd like to have instead.  Would you like
Emacs to instead constantly add and remove tool-bar buttons as they
become available/not available?  I think this would be much more
annoying, and will cause even more people to disable the tool bar.

Making a tool bar insensitive is a standard UI way of telling users:
don't click on this, it will do nothing useful at this time.

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't understand what you'd like to have instead.  Would you like
> Emacs to instead constantly add and remove tool-bar buttons as they
> become available/not available?  I think this would be much more
> annoying, and will cause even more people to disable the tool bar.

We're discussing different options.  I don't think somebody has
suggested dynamically adding/removing buttons from the toolbar, though?

What has been suggested is that only modes where it makes sense should
enable the toolbar (and there probably aren't that many where it makes
much sense).

However, that's probably technically difficult -- people have setups
where they've computed the size of the Emacs windows based on whether
(or not) they have toolbars enabled?  So switching the toolbars on/off
dynamically may lead to some difficulties in that area?

Perhaps modes with "action buttons" (like mpc/eww) should just put the
buttons in the header line.  And then we're back to the original
suggestion: Just default the toolbar to "off".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[Helmut Eller]

On Fri, Dec 18 2020, Lars Ingebrigtsen wrote:

> What has been suggested is that only modes where it makes sense should
> enable the toolbar (and there probably aren't that many where it makes
> much sense).

Maybe there code be something like a "fade-in" toolbar, i.e. normally
the toolbar is hidden but when the mouse pointer moves over the top
border it becomes visible.

Helmut

RE: Emacs Survey: Toolbars

[Drew Adams]

> > What has been suggested is that only modes where it makes sense should
> > enable the toolbar (and there probably aren't that many where it makes
> > much sense).
> 
> Maybe there code be something like a "fade-in" toolbar, i.e. normally
> the toolbar is hidden but when the mouse pointer moves over the top
> border it becomes visible.

`tool-bar+.el' offers something very close to that,
but without the automatic annoyance of it popping
up without explicitly clicking something.

No one has commented on it.  Perhaps no one has
bothered to try it?  It's a single file; just load
it to try it.

https://www.emacswiki.org/emacs/download/tool-bar%2b.el

https://emacswiki.org/emacs/ToolBar

Re: Emacs Survey: Toolbars

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-12-18 21:06]:
> > > What has been suggested is that only modes where it makes sense should
> > > enable the toolbar (and there probably aren't that many where it makes
> > > much sense).
> > 
> > Maybe there code be something like a "fade-in" toolbar, i.e. normally
> > the toolbar is hidden but when the mouse pointer moves over the top
> > border it becomes visible.
> 
> `tool-bar+.el' offers something very close to that,
> but without the automatic annoyance of it popping
> up without explicitly clicking something.
> 
> No one has commented on it.  Perhaps no one has
> bothered to try it?  It's a single file; just load
> it to try it.
> 
> https://www.emacswiki.org/emacs/download/tool-bar%2b.el

Click buttons and tool bar appears, use it and it closes. In my Lucid
toolkit I have to click 2 times Buttons for tool bar to appear. Do you
know that?

Re: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Fri, 18 Dec 2020 10:37:10 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't understand what you'd like to have instead.  Would you like
> > Emacs to instead constantly add and remove tool-bar buttons as they
> > become available/not available?  I think this would be much more
> > annoying, and will cause even more people to disable the tool bar.
> 
> We're discussing different options.  I don't think somebody has
> suggested dynamically adding/removing buttons from the toolbar, though?
> 
> What has been suggested is that only modes where it makes sense should
> enable the toolbar (and there probably aren't that many where it makes
> much sense).

But that's exactly the situation I described above.  Suppose you type
"M-x": this enters the minibuffer, where you have a new mode in
effect, and some (most?) tool-bar buttons make no sense.  Would you
like those buttons, or maybe the entire tool bar, to be removed now?

Similar situation exists when I have 2 windows, one of them showing
*scratch*, and switche between them -- would you like the tool bar to
disappear when I'm in *scratch*?

> However, that's probably technically difficult -- people have setups
> where they've computed the size of the Emacs windows based on whether
> (or not) they have toolbars enabled?  So switching the toolbars on/off
> dynamically may lead to some difficulties in that area?

That's another complication, but we could perhaps handle it in some
reasonable way.  Appearing and disappearing tool bar, OTOH, is
something we need to consider seriously before we decide that such a
mode of tool-bar display is sensible.

Re: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> What has been suggested is that only modes where it makes sense should
>> enable the toolbar (and there probably aren't that many where it makes
>> much sense).
>
> But that's exactly the situation I described above.  Suppose you type
> "M-x": this enters the minibuffer, where you have a new mode in
> effect, and some (most?) tool-bar buttons make no sense.  Would you
> like those buttons, or maybe the entire tool bar, to be removed now?
>
> Similar situation exists when I have 2 windows, one of them showing
> *scratch*, and switche between them -- would you like the tool bar to
> disappear when I'm in *scratch*?

No, I wouldn't, which is why I don't really suggest doing this.
Somebody may come up with ideas that makes the proposition workeable,
and I see that Drew has one -- he suggests having a blank toolbar in
these instances, and ... perhaps?  It's a lot of "dead" space real
estate, though, so I'm not really enthusiastic.

In the cases you describe today, Emacs does switch between different
toolbars (if the modes in question have different ones).  For instance,
`C-x m', and you'll get the Message toolbar with things like "Send" and
"Preview".  If you `M-x', Emacs will switch to the non-specific toolbar
with things like "Save", all of them greyed out.  This, perhaps, shows
that Drew's idea is a good one -- it's less confusing showing a
completely blank toolbar than one with all the items greyed out?

>> However, that's probably technically difficult -- people have setups
>> where they've computed the size of the Emacs windows based on whether
>> (or not) they have toolbars enabled?  So switching the toolbars on/off
>> dynamically may lead to some difficulties in that area?
>
> That's another complication, but we could perhaps handle it in some
> reasonable way.  Appearing and disappearing tool bar, OTOH, is
> something we need to consider seriously before we decide that such a
> mode of tool-bar display is sensible.

Definitely.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: Emacs Survey: Toolbars

[Drew Adams]

> No, I wouldn't, which is why I don't really suggest doing this.
> Somebody may come up with ideas that makes the proposition workeable,
> and I see that Drew has one -- he suggests having a blank toolbar in
> these instances, and ... perhaps?  It's a lot of "dead" space real
> estate, though, so I'm not really enthusiastic.

I haven't suggested using a blank tool-bar.

Not at all.  The `tool-bar+.el' code that I
pointed to lets you _not show_ (not have) a
tool bar at all, until you click a menu-bar
pseudo-menu.

When you do that Emacs pops up the tool-bar
only for the duration of one action (tool-bar
action or any other action).

There's no blank tool bar - no wasted space.
As the doc for `tool-bar+.el' makes clear,
that's the point: save screen real estate.

It takes only a minute to go to Emacs Wiki,
download `tool-bar+.el', load it, and try it.
You will immediately see the effect, and
won't have to guess.  You don't have to like
it, but you might want to at least find out
what it is (and isn't).

https://www.emacswiki.org/emacs/download/tool-bar%2b.el

Other approaches are possible.  With only
Lisp (no C, toolkit etc. changes), I came up
with the behavior it offers.  Emacs can no
doubt do something better or different.  But
IMO, `tool-bar+.el' is a good start, and it
or similar could be added to Emacs immediately.

Re: RE: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Sunday, December 20, 2020 at 12:42 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Lars Ingebrigtsen" <larsi@gnus.org>, "Eli Zaretskii" <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, dgutov@yandex.ru
> Subject: RE: Emacs Survey: Toolbars
>
> > No, I wouldn't, which is why I don't really suggest doing this.
> > Somebody may come up with ideas that makes the proposition workeable,
> > and I see that Drew has one -- he suggests having a blank toolbar in
> > these instances, and ... perhaps?  It's a lot of "dead" space real
> > estate, though, so I'm not really enthusiastic.
>
> I haven't suggested using a blank tool-bar.
>
> Not at all.  The `tool-bar+.el' code that I
> pointed to lets you _not show_ (not have) a
> tool bar at all, until you click a menu-bar
> pseudo-menu.
>
> When you do that Emacs pops up the tool-bar
> only for the duration of one action (tool-bar
> action or any other action).
>
> There's no blank tool bar - no wasted space.
> As the doc for `tool-bar+.el' makes clear,
> that's the point: save screen real estate.
>
> It takes only a minute to go to Emacs Wiki,
> download `tool-bar+.el', load it, and try it.
> You will immediately see the effect, and
> won't have to guess.  You don't have to like
> it, but you might want to at least find out
> what it is (and isn't).
>
> https://www.emacswiki.org/emacs/download/tool-bar%2b.el
>
> Other approaches are possible.  With only
> Lisp (no C, toolkit etc. changes), I came up
> with the behavior it offers.  Emacs can no
> doubt do something better or different.  But
> IMO, `tool-bar+.el' is a good start, and it
> or similar could be added to Emacs immediately.

Can't the functionality of the toolbar be provided
by a separate package.  Then if one wants it, he can
require it.

RE: Emacs Survey: Toolbars

[Drew Adams]

> I don't think somebody has
> suggested dynamically adding/removing buttons from the toolbar, though?

I think Christopher did suggest that.  And I think
he suggested that users even be able to easily define
their own toolbar buttons/icons.

But he'll correct me if I'm mistaken in this.

> What has been suggested is that only modes where it makes sense should
> enable the toolbar (and there probably aren't that many where it makes
> much sense).

For some (individual?) definition of "makes sense",
it could well make sense for most modes/buffers.

The point is that different users can work differently.

> However, that's probably technically difficult -- people have setups
> where they've computed the size of the Emacs windows based on whether
> (or not) they have toolbars enabled?  So switching the toolbars on/off
> dynamically may lead to some difficulties in that area?

I already mentioned tool-bar+.el, which lets you
dynamically show and use the tool bar for one-off
use, by clicking a pseudo menu-bar menu name.

The tool-bar appears, you click a button for its
action, then the tool-bar disappears.

Currently this is only per-frame, not per window.

And currently I have to use a menu-bar menu for
the "button" that pops up the tool-bar.  It might
be nicer to have an icon button for this in the
menu-bar, if that were possible.
___


We might also consider having a "hamburger" menu
in the mode-line.  Items in that menu could
show/hide the menu|tool-bar or pop them up for
one-off actions.  That's one more way to save
screen real estate while giving discoverable
access to menus and tool buttons.

Re: Emacs Survey: Toolbars

[Gregory Heytings via Emacs development discussions.]

>
> I also think the poll is heavily biased in favor of either Reddit users 
> (who are largely either power-users, or those who inspire to be), or 
> experienced Emacs users in general.
>

That's not factually correct.

Only 1/3 of the respondents came from Reddit.

And the number of years repondents have been using Emacs is for 1/3 less 
than 4 years, for 1/3 between 4 and 12 years, and for 1/3 more than 12 
years.

Re: Emacs Survey: Toolbars

[Dmitry Gutov]

On 16.12.2020 16:06, Gregory Heytings wrote:
> 
>>
>> I also think the poll is heavily biased in favor of either Reddit 
>> users (who are largely either power-users, or those who inspire to 
>> be), or experienced Emacs users in general.
>>
> 
> That's not factually correct.
> 
> Only 1/3 of the respondents came from Reddit.

Another 20% came from hacker news, and a bit more - from lobste.rs. 
While it's not a given that those respondents are as heavily into Emacs, 
those forums tend to feature power users as well. Regarding the rest, we 
don't really know.

> And the number of years repondents have been using Emacs is for 1/3 less 
> than 4 years, for 1/3 between 4 and 12 years, and for 1/3 more than 12 
> years.

So 70% of the respondents have been using Emacs for more than 4 years. 
I'd say that's pretty far into the "experienced user" category. 
Certainly not people who need to be told how to disable the toolbar, if 
they want to.

And 70% of the respondents disable the toolbar. Might be a coincidence, 
but there is probably a high degree a correlation.

Re: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Wednesday, December 16, 2020 at 4:24 PM
> From: "Dmitry Gutov" <dgutov@yandex.ru>
> To: "Gregory Heytings" <ghe@sdf.org>
> Cc: "Lars Ingebrigtsen" <larsi@gnus.org>, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> On 16.12.2020 16:06, Gregory Heytings wrote:
> >
> >>
> >> I also think the poll is heavily biased in favor of either Reddit
> >> users (who are largely either power-users, or those who inspire to
> >> be), or experienced Emacs users in general.
> >>
> >
> > That's not factually correct.
> >
> > Only 1/3 of the respondents came from Reddit.
>
> Another 20% came from hacker news, and a bit more - from lobste.rs.
> While it's not a given that those respondents are as heavily into Emacs,
> those forums tend to feature power users as well. Regarding the rest, we
> don't really know.
>
> > And the number of years repondents have been using Emacs is for 1/3 less
> > than 4 years, for 1/3 between 4 and 12 years, and for 1/3 more than 12
> > years.
>
> So 70% of the respondents have been using Emacs for more than 4 years.
> I'd say that's pretty far into the "experienced user" category.
> Certainly not people who need to be told how to disable the toolbar, if
> they want to.
>
> And 70% of the respondents disable the toolbar. Might be a coincidence,
> but there is probably a high degree a correlation.
>

It's a big fuckup, particularly when these people continue to insist on their analysis when
the statistics of the data will be biased.  How can then people then expect to be taken
seriously!  Disregard the bad statistics so we can carry on with our argument is their mantra.

Re: Emacs Survey: Toolbars

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

  > Of 7.3K respondents, 5K disable toolbars, which is more than two
  > thirds.  So perhaps toolbars should default to off?  I know toolbars
  > were all the rage in the 90s, but that's apparently not the case now.

  > Opinions?

The people who responded to that survey are certainly not representative
of all users.  They were selected for being users of certain web sites.

That doesn't imply that most users want toolbars.  Maybe hardly anyone
wants toolbars.

So here's an idea.  We could make Emacs display, where the toolbar
would have been, a question:

   Would you like a toolbar here or not?   Yes   No

If you click Yes, that customizes to permanently turn on the toolbar.
If you click No, that customizes to permanently turn off the toolbar.

Each one could offer to click on a web page where you could
register your preference.  That way we would get a complete sample.



-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Wednesday, December 16, 2020 at 6:34 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Lars Ingebrigtsen" <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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. ]]]
>
>   > Of 7.3K respondents, 5K disable toolbars, which is more than two
>   > thirds.  So perhaps toolbars should default to off?  I know toolbars
>   > were all the rage in the 90s, but that's apparently not the case now.
>
>   > Opinions?
>
> The people who responded to that survey are certainly not representative
> of all users.  They were selected for being users of certain web sites.
>
> That doesn't imply that most users want toolbars.  Maybe hardly anyone
> wants toolbars.
>
> So here's an idea.  We could make Emacs display, where the toolbar
> would have been, a question:
>
>    Would you like a toolbar here or not?   Yes   No
>
> If you click Yes, that customizes to permanently turn on the toolbar.
> If you click No, that customizes to permanently turn off the toolbar.
>
> Each one could offer to click on a web page where you could
> register your preference.  That way we would get a complete sample.

Toolbar icons are the equivalent to keybindings for those who use the
mouse.  Rather than arguing about having a toolbar or not, allow the
user to introduce a toolbar icon and associate with it a specific command.

> --
> 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: Emacs Survey: Toolbars

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Date: Wed, 16 Dec 2020 06:54:43 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> Rather than arguing about having a toolbar or not, allow the user to
> introduce a toolbar icon and associate with it a specific command.

This has existed since day one, see tool-bar.el, where you will find
examples of doing just that (the entire default tool bar is defined
using this method).

Re: Emacs Survey: Toolbars

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

  >   Rather than arguing about having a toolbar or not, allow the
  > user to introduce a toolbar icon and associate with it a specific command.

I am not sure what that means, or how it would be different from the
current state of affairs.  Would you please describe concreretely
what feature you're proposing?

-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

> Sent: Thursday, December 17, 2020 at 6:54 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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. ]]]
>
>   >   Rather than arguing about having a toolbar or not, allow the
>   > user to introduce a toolbar icon and associate with it a specific command.
>
> I am not sure what that means, or how it would be different from the
> current state of affairs.  Would you please describe concreretely
> what feature you're proposing?

Currently one defines a keybinding using "global-set-key" or "add-hook"
in their init file.   Or by using "M-x global-set-key" or something similar.
One then attaches a function, another keybinding or whatever to the user
selected key sequence.

Ok , I will tell you about it.  A User Styled Toolbar.  You name an icon
(rather than a keybind) and associate with it the command (which can be an
elisp function - emacs or user defined).  Same functionality as keybinding
but achieved by pressing an icon in the icon tool bar.  Perhaps the icon can
show text or an icon image (using a name from a pre-defined set).

Functionality can be programmed by the user using elisp.  We just provide
a basic library of utilities so even beginners in elisp can just copy and
paste from a basic template and adjust accordingly.  Same as we are doing
with keybindings.  This will cater to those who want to use the mouse rather
than keypresses.  There could be several reasons for that: Repetitive Strain
Injury, Illness, or Personal Injury.  I can relate to that when I injured my
shoulder blade, arm and wrist, a year ago, and could only use the mouse with
a program that performs clicks and a virtual keyboard.  Deciding the default
behaviour of the toolbar is not important.  But phasing it out or stop work
on it based on a cohort of people who say they do not want it, would be a grave
mistake.  But you don't have to listen to me of coarse.

I have also suggested making modus-themes the dafault face for emacs.  I am reviewing
the WCAG AAA International Standard with Protesilaos Stavrou for finding bugs, and
extend functionality and capability,

I also remember encouraging Jose Marchesi on his Recutils Project back in 2013.  I knew
he was on to something and offered to be its maintainer when he  stopped having interest
in it.  Today, Gnu Recutils is back under active development and has been adopted as part
of the infrastructure of guix and GNUnet.




Regards
Christopher



> --
> 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: Emacs Survey: Toolbars

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

Would you like to implement more convenient customization of the
toolbar?

-- 
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: Emacs Survey: Toolbars

[Christopher Dimech]

Dear Richard,

I like the way toolbars are implemented in Gimp.  One can remove the toolbar because
it is set up in another frame.  Similar to the speedbar.  If emacs could do the same,
the toolbar can be disabled and you would not have the problem of vertical shifting.

Alternatively, one could make the toolbar functionality appear as an additional MenuItem
that you could detach.  By keeping two screens - one side emacs, the other with the detached
toolbar, a mouse clicking tool, and a virtual keyboard - one can mark quite well.

The problem with all this is whether the trend is to get rid of toolbars altogether.  That's
the  real problem.  If a way can be found that does not require the toolbar to take space
on the frame, it could make people who do not want it happy.  The others can have the freedom
to develop the toolbar or do work for others with it.  I would be willing to include it in
my Behistun Package, although have not planned on it.  Then send they code for inclusion
in emacs.  But first one has to see how the emacs code on toolbars is applied differently
by the maintaners as they adapt to the many people that insist on not having the toolbar
visible.

Have not coded in GTK for a long time.

Regards
Christopher

> Sent: Friday, December 18, 2020 at 6:41 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> Subject: Re: Emacs Survey: Toolbars
>
> [[[ 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. ]]]
>
> Would you like to implement more convenient customization of the
> toolbar?
>
> --
> 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: Emacs Survey: Toolbars

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> That doesn't imply that most users want toolbars.  Maybe hardly anyone
> wants toolbars.
>
> So here's an idea.  We could make Emacs display, where the toolbar
> would have been, a question:
>
>    Would you like a toolbar here or not?   Yes   No
>
> If you click Yes, that customizes to permanently turn on the toolbar.
> If you click No, that customizes to permanently turn off the toolbar.

I think that sounds slightly intrusive...  but we certainly could have
something in the menu area for that: A mouse-3 popup that switches the
toolbar on/off, for instance.

> Each one could offer to click on a web page where you could
> register your preference.  That way we would get a complete sample.

I'm not very enthusiastic about that -- it smacks a bit of
"telemetry".  We don't want Emacs to be seen as a piece of software that
"phones home" and leaks data.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Emacs Survey: Toolbars

[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 here's an idea.  We could make Emacs display, where the toolbar
  > > would have been, a question:
  > >
  > >    Would you like a toolbar here or not?   Yes   No
  > >
  > > If you click Yes, that customizes to permanently turn on the toolbar.
  > > If you click No, that customizes to permanently turn off the toolbar.

  > I think that sounds slightly intrusive...

Why would it be more intrusive than the toolbar currently is?
It would occupy the same screen area.

  >   but we certainly could have
  > something in the menu area for that: A mouse-3 popup that switches the
  > toolbar on/off, for instance.

Yes, we could do that, but it would not encourage people to actually
answer the question.


  > > Each one could offer to click on a web page where you could
  > > register your preference.  That way we would get a complete sample.

  > I'm not very enthusiastic about that -- it smacks a bit of
  > "telemetry".

That is a misjudgment.  There is nothing wrong with inviting the user
to communicate.

  >   We don't want Emacs to be seen as a piece of software that
  > "phones home" and leaks data.

I agree, but what I am proposing is not that.

  > In the mega-thread about modernising Emacs, the common refrain was that
  > we needed actual data on what users do.  We now have some data, and I
  > don't think we should just dismiss that data because of statistical
  > quibbles.

My suggestion will get us very good data about this question.

-- 
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: Emacs Survey: Toolbars

[chad]

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

One interesting bit of data from Dick Mao's survey analysis centers around
keybinding sets. Very roughly, about 2/3 of respondents use the default
keybindings, and the other third use evil-mode. The correlation that seems
relevant:

The median evil-modalist is *seven emacs-years younger* than the median
> traditionalist.


Reading the tea-leaves a bit, I think this suggests that at least many of
these younger users are NOT seeing the toolbar normally, since the vast
majority of the ways that a newer user is likely to get to vi-style
bindings (via packaged setups like spacemacs or doom, by following
config-file advice from the community, etc.)  also disable the toolbar.

This supports the (widespread?) theory that for most new users, the toolbar
is present only at the very earliest moments of using emacs, if that.

~Chad

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