RE: Auto Fill Comments

RE: Auto Fill Comments

[Drew Adams]

> > Yes, Emacs terminology is old.
> 
> Which is why we have an elaborate Glossary chapter in the manual.

+1.
________


I'll mention also (definitely not _instead_)
that Emacs Wiki has a Glossary page:

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

(There's also a link to it at the top left of
every wiki page - hard to miss.)

And more generally, there's even a Glossary
_category_ page, which points to other pages
that explain or cover things in more detail:

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

And all of that is easily findable from the
main wiki page - categories are listed there,
and there's Search:

https://www.emacswiki.org/

As is the case for most Emacs Wiki pages,
anyone can contribute to (edit) the Glossary
page.  So it presents terminology as many
different Emacs _users_ see it.  The page
may help you, or not.

(And many wiki pages are available in other
languages besides English.  And _you_ can
translate a page or improve a translation.)

The point is that people have tried to help
each other better understand Emacs and its
terminology, in different ways, with their
own voices.

Instead of just complaining about someone
else's attempt to describe, define, or
explain something, you can pitch in and
help in your own way.  You can add wiki
pages and edit existing pages.  You can
write your own Emacs manual there, if you
like...

Most importantly, you can take advantage of
this aid from other users.

I _do_ strongly recommend the Glossary in
the Emacs manual, but no one is limited to
any particular "official" presentation or
interpretation of such things.

There's little excuse for complaining that
there's "too much" help, or it's not clear
enough, or whatever.  In my humble opinion.

I also recommend these guiding wiki pages:

Newbie: https://www.emacswiki.org/emacs/EmacsNewbie

Learning Emacs: https://www.emacswiki.org/emacs/LearningEmacs

Learning Elisp: https://www.emacswiki.org/emacs/LearnEmacsLisp

Category Doc: https://www.emacswiki.org/emacs/CategoryDocumentation

The wiki is for everyone. You can contribute,
you can ask questions there,...  It's yours
(if you want it).
________


BTW, if you use my library Info+, then by default:

Glossary words, that is, words that are defined
in a manual's `Glossary' node, are highlighted
and linked to their glossary entries, if option
`Info-fontify-glossary-words' is non-`nil'.  

By default, a mouseover on such a link shows a
tooltip with the word's definition from the
glossary, and either `mouse-2' or `RET' on a
link takes you to the entry in the Glossary.
And glossary entries that mention other entries
link to them.

By default, words in all manuals are linked
to the `Glossary' node of the _Emacs_ manual.
But you can control which manuals use which
glossaries (or none), using option
`Info-glossary-fallbacks-alist'.

(Currently only the Emacs and Semantic manuals
have `Glossary' nodes, as far as I know.  But
I use only the Info manuals provided by default
with GNU Emacs on MS Windows.)

,----
| Info-glossary-fallbacks-alist is a variable
| defined in `info+.el'. Its value is ((emacs . t))
| 
| Documentation:
| Alist of fallback manuals to use for glossary links.
|
| Each element is of the form (GLOSSARY-MANUAL . MANUALS).
| The glossary of GLOSSARY-MANUAL is used to create
| glossary links for each manual in MANUALS, if it has
| no glossary of its own.  If MANUALS is `t' then all
| manuals use the glossary of GLOSSARY-MANUAL.
| 
| This has no effect if option
| `Info-fontify-glossary-words' is nil.
| 
| You can customize this variable.
`----

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

Code: https://www.emacswiki.org/emacs/download/info%2b.el

Re: Auto Fill Comments

[Jean Louis]

Hello Drew,

How do you get these drawings below?

Jean

* Drew Adams <drew.adams@oracle.com> [2020-11-27 20:52]:
\> ,----
> | Info-glossary-fallbacks-alist is a variable
> | defined in `info+.el'. Its value is ((emacs . t))
> | 
> | Documentation:
> | Alist of fallback manuals to use for glossary links.
> |
> | Each element is of the form (GLOSSARY-MANUAL . MANUALS).
> | The glossary of GLOSSARY-MANUAL is used to create
> | glossary links for each manual in MANUALS, if it has
> | no glossary of its own.  If MANUALS is `t' then all
> | manuals use the glossary of GLOSSARY-MANUAL.
> | 
> | This has no effect if option
> | `Info-fontify-glossary-words' is nil.
> | 
> | You can customize this variable.
> `----

RE: Auto Fill Comments

[Drew Adams]

> How do you get these drawings below?
>
> \> ,----
> > | Info-glossary-fallbacks-alist is a variable
> > | defined in `info+.el'. Its value is ((emacs . t))
> > |...
> > `----

Command `boxquote-region', from library `boxquote.el'.

https://github.com/davep/boxquote.el

Re: Auto Fill Comments

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-11-27 22:01]:
> > How do you get these drawings below?
> >
> > \> ,----
> > > | Info-glossary-fallbacks-alist is a variable
> > > | defined in `info+.el'. Its value is ((emacs . t))
> > > |...
> > > `----
> 
> Command `boxquote-region', from library `boxquote.el'.
>
,----
| https://github.com/davep/boxquote.el
`----

Thank you, works well.

Auto Fill Comments

[Christopher Dimech]

Would this be good enough  to Auto Fill Comments in c language.
What can I use for Auto Fill Comments for other languages, e.g.
fortran, elisp, c++, texinfo, bash, awk, org, R.

;; Apply Auto Fill to comments but not code in programming language modes.
(add-hook 'c-mode-common-hook
   (lambda ()
      (auto-fill-mode 1)
      (set
         (make-local-variable 'fill-nobreak-predicate)
         (lambda ()
            (not (eq (get-text-property (point) 'face)
                    'font-lock-comment-face)))) ))

Re: Auto Fill Comments

[daniela-spit]

This is what I use.  I find no good reason to use c-mode-common-hook.

(defun break-comment ()
   (setq-local comment-auto-fill-only-comments t)
   (auto-fill-mode 1))

(add-hook 'sh-mode-hook          #'break-comment)
(add-hook 'fortran-mode-hook     #'break-comment)
(add-hook 'emacs-lisp-mode-hook  #'break-comment)
(add-hook 'texinfo-mode-hook     #'break-comment)

(add-hook 'c-mode-hook       #'break-comment)
(add-hook 'c++-mode-hook     #'break-comment)
(add-hook 'awk-mode-hook     #'break-comment)
(add-hook 'R-mode-hook       #'break-comment)
(add-hook 'octave-mode-hook  #'break-comment)
(add-hook 'text-mode-hook    #'break-comment)


> Sent: Tuesday, November 24, 2020 at 6:05 PM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Auto Fill Comments
>
> Would this be good enough  to Auto Fill Comments in c language.
> What can I use for Auto Fill Comments for other languages, e.g.
> fortran, elisp, c++, texinfo, bash, awk, org, R.
>
> ;; Apply Auto Fill to comments but not code in programming language modes.
> (add-hook 'c-mode-common-hook
>    (lambda ()
>       (auto-fill-mode 1)
>       (set
>          (make-local-variable 'fill-nobreak-predicate)
>          (lambda ()
>             (not (eq (get-text-property (point) 'face)
>                     'font-lock-comment-face)))) ))
>
>
>

Re: Auto Fill Comments

[Christopher Dimech]

Looks quite nice.  I could try to cycle through three states:
(1) auto fill comments; (2) auto fill buffer; and (3) disable
auto fill.

Anybody done this before?

Regards
Christopher



> Sent: Tuesday, November 24, 2020 at 8:42 PM
> From: daniela-spit@gmx.it
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Auto Fill Comments
>
> This is what I use.  I find no good reason to use c-mode-common-hook.
>
> (defun break-comment ()
>    (setq-local comment-auto-fill-only-comments t)
>    (auto-fill-mode 1))
>
> (add-hook 'sh-mode-hook          #'break-comment)
> (add-hook 'fortran-mode-hook     #'break-comment)
> (add-hook 'emacs-lisp-mode-hook  #'break-comment)
> (add-hook 'texinfo-mode-hook     #'break-comment)
>
> (add-hook 'c-mode-hook       #'break-comment)
> (add-hook 'c++-mode-hook     #'break-comment)
> (add-hook 'awk-mode-hook     #'break-comment)
> (add-hook 'R-mode-hook       #'break-comment)
> (add-hook 'octave-mode-hook  #'break-comment)
> (add-hook 'text-mode-hook    #'break-comment)
>
>
> > Sent: Tuesday, November 24, 2020 at 6:05 PM
> > From: "Christopher Dimech" <dimech@gmx.com>
> > To: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> > Subject: Auto Fill Comments
> >
> > Would this be good enough  to Auto Fill Comments in c language.
> > What can I use for Auto Fill Comments for other languages, e.g.
> > fortran, elisp, c++, texinfo, bash, awk, org, R.
> >
> > ;; Apply Auto Fill to comments but not code in programming language modes.
> > (add-hook 'c-mode-common-hook
> >    (lambda ()
> >       (auto-fill-mode 1)
> >       (set
> >          (make-local-variable 'fill-nobreak-predicate)
> >          (lambda ()
> >             (not (eq (get-text-property (point) 'face)
> >                     'font-lock-comment-face)))) ))
> >
> >
> >
>

Re: Auto Fill Comments

[daniela-spit]

> Sent: Tuesday, November 24, 2020 at 8:52 PM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: daniela-spit@gmx.it
> Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Auto Fill Comments
>
> Looks quite nice.  I could try to cycle through three states:
> (1) auto fill comments; (2) auto fill buffer; and (3) disable
> auto fill.
>
> Anybody done this before?

I have not, don't know much elisp myself.

> Regards
> Christopher
>
>
>
> > Sent: Tuesday, November 24, 2020 at 8:42 PM
> > From: daniela-spit@gmx.it
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> > Subject: Re: Auto Fill Comments
> >
> > This is what I use.  I find no good reason to use c-mode-common-hook.
> >
> > (defun break-comment ()
> >    (setq-local comment-auto-fill-only-comments t)
> >    (auto-fill-mode 1))
> >
> > (add-hook 'sh-mode-hook          #'break-comment)
> > (add-hook 'fortran-mode-hook     #'break-comment)
> > (add-hook 'emacs-lisp-mode-hook  #'break-comment)
> > (add-hook 'texinfo-mode-hook     #'break-comment)
> >
> > (add-hook 'c-mode-hook       #'break-comment)
> > (add-hook 'c++-mode-hook     #'break-comment)
> > (add-hook 'awk-mode-hook     #'break-comment)
> > (add-hook 'R-mode-hook       #'break-comment)
> > (add-hook 'octave-mode-hook  #'break-comment)
> > (add-hook 'text-mode-hook    #'break-comment)
> >
> >
> > > Sent: Tuesday, November 24, 2020 at 6:05 PM
> > > From: "Christopher Dimech" <dimech@gmx.com>
> > > To: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> > > Subject: Auto Fill Comments
> > >
> > > Would this be good enough  to Auto Fill Comments in c language.
> > > What can I use for Auto Fill Comments for other languages, e.g.
> > > fortran, elisp, c++, texinfo, bash, awk, org, R.
> > >
> > > ;; Apply Auto Fill to comments but not code in programming language modes.
> > > (add-hook 'c-mode-common-hook
> > >    (lambda ()
> > >       (auto-fill-mode 1)
> > >       (set
> > >          (make-local-variable 'fill-nobreak-predicate)
> > >          (lambda ()
> > >             (not (eq (get-text-property (point) 'face)
> > >                     'font-lock-comment-face)))) ))
> > >
> > >
> > >
> >
>

Re: Auto Fill Comments

[Christopher Dimech]

Have started doing something, but am quite stuck now.  Somehow I need to
fill the list for the three options: (1) autofill comments; (2) autofill
buffer; and (3) disable autofill.

(setq autofill-list
   '( ))

(defun break-line-cycle (@n)
   (interactive "p")
   ;; Sets property 'state', an integer. Possible values are any index
   ;; to autofill-list.
   (let ($fill-selector $cnd-before $cnd-after)
      (setq $cnd-before
         (if (get 'break-line-cycle 'state)
           (get 'break-line-cycle 'state)
           0) )
      (setq $cnd-after
         (% (+ $cnd-before (length font-list) @n) (length autofill-list)))
      (setq $fill-selector (nth $cnd-after autofill-list))
      (put 'break-line-cycle 'state $cnd-after)))

> Sent: Tuesday, November 24, 2020 at 8:52 PM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: daniela-spit@gmx.it
> Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Auto Fill Comments
>
> Looks quite nice.  I could try to cycle through three states:
> (1) auto fill comments; (2) auto fill buffer; and (3) disable
> auto fill.
>
> Anybody done this before?
>
> Regards
> Christopher
>
>
>
> > Sent: Tuesday, November 24, 2020 at 8:42 PM
> > From: daniela-spit@gmx.it
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> > Subject: Re: Auto Fill Comments
> >
> > This is what I use.  I find no good reason to use c-mode-common-hook.
> >
> > (defun break-comment ()
> >    (setq-local comment-auto-fill-only-comments t)
> >    (auto-fill-mode 1))
> >
> > (add-hook 'sh-mode-hook          #'break-comment)
> > (add-hook 'fortran-mode-hook     #'break-comment)
> > (add-hook 'emacs-lisp-mode-hook  #'break-comment)
> > (add-hook 'texinfo-mode-hook     #'break-comment)
> >
> > (add-hook 'c-mode-hook       #'break-comment)
> > (add-hook 'c++-mode-hook     #'break-comment)
> > (add-hook 'awk-mode-hook     #'break-comment)
> > (add-hook 'R-mode-hook       #'break-comment)
> > (add-hook 'octave-mode-hook  #'break-comment)
> > (add-hook 'text-mode-hook    #'break-comment)
> >
> >
> > > Sent: Tuesday, November 24, 2020 at 6:05 PM
> > > From: "Christopher Dimech" <dimech@gmx.com>
> > > To: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> > > Subject: Auto Fill Comments
> > >
> > > Would this be good enough  to Auto Fill Comments in c language.
> > > What can I use for Auto Fill Comments for other languages, e.g.
> > > fortran, elisp, c++, texinfo, bash, awk, org, R.
> > >
> > > ;; Apply Auto Fill to comments but not code in programming language modes.
> > > (add-hook 'c-mode-common-hook
> > >    (lambda ()
> > >       (auto-fill-mode 1)
> > >       (set
> > >          (make-local-variable 'fill-nobreak-predicate)
> > >          (lambda ()
> > >             (not (eq (get-text-property (point) 'face)
> > >                     'font-lock-comment-face)))) ))
> > >
> > >
> > >
> >
>

---------------------
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

Re: Auto Fill Comments

[Christopher Dimech]

The biggest problem is how to call autofill parameters as the three list
options change.

> Sent: Tuesday, November 24, 2020 at 9:53 PM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Auto Fill Comments
>
> Have started doing something, but am quite stuck now.  Somehow I need to
> fill the list for the three options: (1) autofill comments; (2) autofill
> buffer; and (3) disable autofill.
>
> (setq autofill-list
>    '( ))
>
> (defun break-line-cycle (@n)
>    (interactive "p")
>    ;; Sets property 'state', an integer. Possible values are any index
>    ;; to autofill-list.
>    (let ($fill-selector $cnd-before $cnd-after)
>       (setq $cnd-before
>          (if (get 'break-line-cycle 'state)
>            (get 'break-line-cycle 'state)
>            0) )
>       (setq $cnd-after
>          (% (+ $cnd-before (length font-list) @n) (length autofill-list)))
>       (setq $fill-selector (nth $cnd-after autofill-list))
>       (put 'break-line-cycle 'state $cnd-after)))
>
> > Sent: Tuesday, November 24, 2020 at 8:52 PM
> > From: "Christopher Dimech" <dimech@gmx.com>
> > To: daniela-spit@gmx.it
> > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> > Subject: Re: Auto Fill Comments
> >
> > Looks quite nice.  I could try to cycle through three states:
> > (1) auto fill comments; (2) auto fill buffer; and (3) disable
> > auto fill.
> >
> > Anybody done this before?
> >
> > Regards
> > Christopher
> >
> >
> >
> > > Sent: Tuesday, November 24, 2020 at 8:42 PM
> > > From: daniela-spit@gmx.it
> > > To: "Christopher Dimech" <dimech@gmx.com>
> > > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> > > Subject: Re: Auto Fill Comments
> > >
> > > This is what I use.  I find no good reason to use c-mode-common-hook.
> > >
> > > (defun break-comment ()
> > >    (setq-local comment-auto-fill-only-comments t)
> > >    (auto-fill-mode 1))
> > >
> > > (add-hook 'sh-mode-hook          #'break-comment)
> > > (add-hook 'fortran-mode-hook     #'break-comment)
> > > (add-hook 'emacs-lisp-mode-hook  #'break-comment)
> > > (add-hook 'texinfo-mode-hook     #'break-comment)
> > >
> > > (add-hook 'c-mode-hook       #'break-comment)
> > > (add-hook 'c++-mode-hook     #'break-comment)
> > > (add-hook 'awk-mode-hook     #'break-comment)
> > > (add-hook 'R-mode-hook       #'break-comment)
> > > (add-hook 'octave-mode-hook  #'break-comment)
> > > (add-hook 'text-mode-hook    #'break-comment)
> > >
> > >
> > > > Sent: Tuesday, November 24, 2020 at 6:05 PM
> > > > From: "Christopher Dimech" <dimech@gmx.com>
> > > > To: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> > > > Subject: Auto Fill Comments
> > > >
> > > > Would this be good enough  to Auto Fill Comments in c language.
> > > > What can I use for Auto Fill Comments for other languages, e.g.
> > > > fortran, elisp, c++, texinfo, bash, awk, org, R.
> > > >
> > > > ;; Apply Auto Fill to comments but not code in programming language modes.
> > > > (add-hook 'c-mode-common-hook
> > > >    (lambda ()
> > > >       (auto-fill-mode 1)
> > > >       (set
> > > >          (make-local-variable 'fill-nobreak-predicate)
> > > >          (lambda ()
> > > >             (not (eq (get-text-property (point) 'face)
> > > >                     'font-lock-comment-face)))) ))
> > > >
> > > >
> > > >
> > >
> >
>
> ---------------------
> 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
>

Re: Auto Fill Comments

[Dante Catalfamo]

Is there any reason you don't add a hook to prog-mode instead? Are there 
some languages that don't have well defined comments?

On 11/24/20 2:42 PM, daniela-spit@gmx.it wrote:
> This is what I use.  I find no good reason to use c-mode-common-hook.
> 
> (defun break-comment ()
>     (setq-local comment-auto-fill-only-comments t)
>     (auto-fill-mode 1))
> 
> (add-hook 'sh-mode-hook          #'break-comment)
> (add-hook 'fortran-mode-hook     #'break-comment)
> (add-hook 'emacs-lisp-mode-hook  #'break-comment)
> (add-hook 'texinfo-mode-hook     #'break-comment)
> 
> (add-hook 'c-mode-hook       #'break-comment)
> (add-hook 'c++-mode-hook     #'break-comment)
> (add-hook 'awk-mode-hook     #'break-comment)
> (add-hook 'R-mode-hook       #'break-comment)
> (add-hook 'octave-mode-hook  #'break-comment)
> (add-hook 'text-mode-hook    #'break-comment)
> 
> 
>> Sent: Tuesday, November 24, 2020 at 6:05 PM
>> From: "Christopher Dimech" <dimech@gmx.com>
>> To: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
>> Subject: Auto Fill Comments
>>
>> Would this be good enough  to Auto Fill Comments in c language.
>> What can I use for Auto Fill Comments for other languages, e.g.
>> fortran, elisp, c++, texinfo, bash, awk, org, R.
>>
>> ;; Apply Auto Fill to comments but not code in programming language modes.
>> (add-hook 'c-mode-common-hook
>>     (lambda ()
>>        (auto-fill-mode 1)
>>        (set
>>           (make-local-variable 'fill-nobreak-predicate)
>>           (lambda ()
>>              (not (eq (get-text-property (point) 'face)
>>                      'font-lock-comment-face)))) ))
>>
>>
>>
> 

Re: Auto Fill Comments

[Christopher Dimech]

Because I thought that I can have a keybinding that cycles
auto-fill.  It could be long and hard to do that for every
major mode.

There are times when I need to also have the code use auto-fill,
but not always.  A keybinding cycle could be a solution for every
major mode.

> Sent: Friday, November 27, 2020 at 5:40 AM
> From: "Dante Catalfamo" <dante@lambda.cx>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Is there any reason you don't add a hook to prog-mode instead? Are there
> some languages that don't have well defined comments?
>
> On 11/24/20 2:42 PM, daniela-spit@gmx.it wrote:
> > This is what I use.  I find no good reason to use c-mode-common-hook.
> >
> > (defun break-comment ()
> >     (setq-local comment-auto-fill-only-comments t)
> >     (auto-fill-mode 1))
> >
> > (add-hook 'sh-mode-hook          #'break-comment)
> > (add-hook 'fortran-mode-hook     #'break-comment)
> > (add-hook 'emacs-lisp-mode-hook  #'break-comment)
> > (add-hook 'texinfo-mode-hook     #'break-comment)
> >
> > (add-hook 'c-mode-hook       #'break-comment)
> > (add-hook 'c++-mode-hook     #'break-comment)
> > (add-hook 'awk-mode-hook     #'break-comment)
> > (add-hook 'R-mode-hook       #'break-comment)
> > (add-hook 'octave-mode-hook  #'break-comment)
> > (add-hook 'text-mode-hook    #'break-comment)
> >
> >
> >> Sent: Tuesday, November 24, 2020 at 6:05 PM
> >> From: "Christopher Dimech" <dimech@gmx.com>
> >> To: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>
> >> Subject: Auto Fill Comments
> >>
> >> Would this be good enough  to Auto Fill Comments in c language.
> >> What can I use for Auto Fill Comments for other languages, e.g.
> >> fortran, elisp, c++, texinfo, bash, awk, org, R.
> >>
> >> ;; Apply Auto Fill to comments but not code in programming language modes.
> >> (add-hook 'c-mode-common-hook
> >>     (lambda ()
> >>        (auto-fill-mode 1)
> >>        (set
> >>           (make-local-variable 'fill-nobreak-predicate)
> >>           (lambda ()
> >>              (not (eq (get-text-property (point) 'face)
> >>                      'font-lock-comment-face)))) ))
> >>
> >>
> >>
> >
>
>

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

> Because I thought that I can have a keybinding that cycles
> auto-fill.
What exactly are your trying to cycle? Autofill breaks lines. Works
fine here, I have it always on. I am intrigating by the discussion,
I wonder what is your use case?

> It could be long and hard to do that for every
> major mode.
Aren't minor modes for that use-case.

> There are times when I need to also have the code use auto-fill,
> but not always.  A keybinding cycle could be a solution for every
> major mode.
What exactly are you trying to do?


Maybe it is already done; maybe there is something similar; maybe you
are asking something impossible or very hard. What exactly are you
trying to achieve? A minor mode sounds like something you are looking
for. Have you checked fill commands?

https://www.gnu.org/software/emacs/manual/html_node/emacs/Fill-Commands.html#Fill-Commands

Maybe you need to puzzle together your own funcionallity for your own
particular workflow.

Re: Auto Fill Comments

[Robert Thorpe]

Christopher Dimech <dimech@gmx.com> writes:

> Would this be good enough  to Auto Fill Comments in c language.
> What can I use for Auto Fill Comments for other languages, e.g.
> fortran, elisp, c++, texinfo, bash, awk, org, R.
>
> ;; Apply Auto Fill to comments but not code in programming language modes.
> (add-hook 'c-mode-common-hook
>    (lambda ()
>       (auto-fill-mode 1)
>       (set
>          (make-local-variable 'fill-nobreak-predicate)
>          (lambda ()
>             (not (eq (get-text-property (point) 'face)
>                     'font-lock-comment-face)))) ))

Notice that "M-q" performs paragraph filling for comments in C and other
languages.  It is not *auto* filling certainly, but it's very useful.

I've found that to be the best myself.  That's because of commenting out
code.  The problem is if you comment out code then modify it when it's a
comment.  If you set Emacs to auto-fill comments, then it will auto-fill
those code comments as though they're text.  That's wrong when you want
to uncomment the block and make it back into code, it removes the
indentation.

BR,
Robert Thorpe

Re: Auto Fill Comments

[Christopher Dimech]

M-q was what I have been doing.  Want to try out auto fill, see if it can save me
using the key binding.  I usually keep code quite compact, but will check out
what you discussed.


> Sent: Wednesday, November 25, 2020 at 8:11 AM
> From: "Robert Thorpe" <rt@robertthorpeconsulting.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Would this be good enough  to Auto Fill Comments in c language.
> > What can I use for Auto Fill Comments for other languages, e.g.
> > fortran, elisp, c++, texinfo, bash, awk, org, R.
> >
> > ;; Apply Auto Fill to comments but not code in programming language modes.
> > (add-hook 'c-mode-common-hook
> >    (lambda ()
> >       (auto-fill-mode 1)
> >       (set
> >          (make-local-variable 'fill-nobreak-predicate)
> >          (lambda ()
> >             (not (eq (get-text-property (point) 'face)
> >                     'font-lock-comment-face)))) ))
>
> Notice that "M-q" performs paragraph filling for comments in C and other
> languages.  It is not *auto* filling certainly, but it's very useful.
>
> I've found that to be the best myself.  That's because of commenting out
> code.  The problem is if you comment out code then modify it when it's a
> comment.  If you set Emacs to auto-fill comments, then it will auto-fill
> those code comments as though they're text.  That's wrong when you want
> to uncomment the block and make it back into code, it removes the
> indentation.
>
> BR,
> Robert Thorpe
>
>
>

Re: Auto Fill Comments

[Christopher Dimech]

I am still stuck with trying to do autofill by cycling through a key binding.
In summary I want to cycle between

1. Auto Fill only comments
2. Auto Fill entire buffer
3. Disable Auto Fill

What command can be used to set the three commands?

> Sent: Wednesday, November 25, 2020 at 8:59 AM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: "Robert Thorpe" <rt@robertthorpeconsulting.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> M-q was what I have been doing.  Want to try out auto fill, see if it can save me
> using the key binding.  I usually keep code quite compact, but will check out
> what you discussed.
>
>
> > Sent: Wednesday, November 25, 2020 at 8:11 AM
> > From: "Robert Thorpe" <rt@robertthorpeconsulting.com>
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: help-gnu-emacs@gnu.org
> > Subject: Re: Auto Fill Comments
> >
> > Christopher Dimech <dimech@gmx.com> writes:
> >
> > > Would this be good enough  to Auto Fill Comments in c language.
> > > What can I use for Auto Fill Comments for other languages, e.g.
> > > fortran, elisp, c++, texinfo, bash, awk, org, R.
> > >
> > > ;; Apply Auto Fill to comments but not code in programming language modes.
> > > (add-hook 'c-mode-common-hook
> > >    (lambda ()
> > >       (auto-fill-mode 1)
> > >       (set
> > >          (make-local-variable 'fill-nobreak-predicate)
> > >          (lambda ()
> > >             (not (eq (get-text-property (point) 'face)
> > >                     'font-lock-comment-face)))) ))
> >
> > Notice that "M-q" performs paragraph filling for comments in C and other
> > languages.  It is not *auto* filling certainly, but it's very useful.
> >
> > I've found that to be the best myself.  That's because of commenting out
> > code.  The problem is if you comment out code then modify it when it's a
> > comment.  If you set Emacs to auto-fill comments, then it will auto-fill
> > those code comments as though they're text.  That's wrong when you want
> > to uncomment the block and make it back into code, it removes the
> > indentation.
> >
> > BR,
> > Robert Thorpe
> >
> >
> >
>
>

Re: Auto Fill Comments

[daniela-spit]

We currently have just a hook to text-mode

(add-hook 'text-mode-hook
   '(lambda()
       (turn-on-auto-fill)
       (set-fill-column 80) ))

> Sent: Thursday, November 26, 2020 at 4:56 AM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
>
> I am still stuck with trying to do autofill by cycling through a key binding.
> In summary I want to cycle between
>
> 1. Auto Fill only comments
> 2. Auto Fill entire buffer
> 3. Disable Auto Fill
>
> What command can be used to set the three commands?
>
> > Sent: Wednesday, November 25, 2020 at 8:59 AM
> > From: "Christopher Dimech" <dimech@gmx.com>
> > To: "Robert Thorpe" <rt@robertthorpeconsulting.com>
> > Cc: help-gnu-emacs@gnu.org
> > Subject: Re: Auto Fill Comments
> >
> > M-q was what I have been doing.  Want to try out auto fill, see if it can save me
> > using the key binding.  I usually keep code quite compact, but will check out
> > what you discussed.
> >
> >
> > > Sent: Wednesday, November 25, 2020 at 8:11 AM
> > > From: "Robert Thorpe" <rt@robertthorpeconsulting.com>
> > > To: "Christopher Dimech" <dimech@gmx.com>
> > > Cc: help-gnu-emacs@gnu.org
> > > Subject: Re: Auto Fill Comments
> > >
> > > Christopher Dimech <dimech@gmx.com> writes:
> > >
> > > > Would this be good enough  to Auto Fill Comments in c language.
> > > > What can I use for Auto Fill Comments for other languages, e.g.
> > > > fortran, elisp, c++, texinfo, bash, awk, org, R.
> > > >
> > > > ;; Apply Auto Fill to comments but not code in programming language modes.
> > > > (add-hook 'c-mode-common-hook
> > > >    (lambda ()
> > > >       (auto-fill-mode 1)
> > > >       (set
> > > >          (make-local-variable 'fill-nobreak-predicate)
> > > >          (lambda ()
> > > >             (not (eq (get-text-property (point) 'face)
> > > >                     'font-lock-comment-face)))) ))
> > >
> > > Notice that "M-q" performs paragraph filling for comments in C and other
> > > languages.  It is not *auto* filling certainly, but it's very useful.
> > >
> > > I've found that to be the best myself.  That's because of commenting out
> > > code.  The problem is if you comment out code then modify it when it's a
> > > comment.  If you set Emacs to auto-fill comments, then it will auto-fill
> > > those code comments as though they're text.  That's wrong when you want
> > > to uncomment the block and make it back into code, it removes the
> > > indentation.
> > >
> > > BR,
> > > Robert Thorpe
> > >
> > >
> > >
> >
> >
>
>

Re: Auto Fill Comments

[Christopher Dimech]

I am getting somewhat confused because I have also seen
people using set-fill-column and setq-default.

Is doing fill-column and set-fill-column the same thing?


(add-hook 'text-mode-hook
   '(lambda()
       (turn-on-auto-fill)
       (set-fill-column 72) ))

(setq-default fill-column 72)



> Sent: Thursday, November 26, 2020 at 4:13 PM
> From: daniela-spit@gmx.it
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> We currently have just a hook to text-mode
>
> (add-hook 'text-mode-hook
>    '(lambda()
>        (turn-on-auto-fill)
>        (set-fill-column 80) ))
>
> > Sent: Thursday, November 26, 2020 at 4:56 AM
> > From: "Christopher Dimech" <dimech@gmx.com>
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: help-gnu-emacs@gnu.org
> > Subject: Re: Auto Fill Comments
> >
> >
> > I am still stuck with trying to do autofill by cycling through a key binding.
> > In summary I want to cycle between
> >
> > 1. Auto Fill only comments
> > 2. Auto Fill entire buffer
> > 3. Disable Auto Fill
> >
> > What command can be used to set the three commands?
> >
> > > Sent: Wednesday, November 25, 2020 at 8:59 AM
> > > From: "Christopher Dimech" <dimech@gmx.com>
> > > To: "Robert Thorpe" <rt@robertthorpeconsulting.com>
> > > Cc: help-gnu-emacs@gnu.org
> > > Subject: Re: Auto Fill Comments
> > >
> > > M-q was what I have been doing.  Want to try out auto fill, see if it can save me
> > > using the key binding.  I usually keep code quite compact, but will check out
> > > what you discussed.
> > >
> > >
> > > > Sent: Wednesday, November 25, 2020 at 8:11 AM
> > > > From: "Robert Thorpe" <rt@robertthorpeconsulting.com>
> > > > To: "Christopher Dimech" <dimech@gmx.com>
> > > > Cc: help-gnu-emacs@gnu.org
> > > > Subject: Re: Auto Fill Comments
> > > >
> > > > Christopher Dimech <dimech@gmx.com> writes:
> > > >
> > > > > Would this be good enough  to Auto Fill Comments in c language.
> > > > > What can I use for Auto Fill Comments for other languages, e.g.
> > > > > fortran, elisp, c++, texinfo, bash, awk, org, R.
> > > > >
> > > > > ;; Apply Auto Fill to comments but not code in programming language modes.
> > > > > (add-hook 'c-mode-common-hook
> > > > >    (lambda ()
> > > > >       (auto-fill-mode 1)
> > > > >       (set
> > > > >          (make-local-variable 'fill-nobreak-predicate)
> > > > >          (lambda ()
> > > > >             (not (eq (get-text-property (point) 'face)
> > > > >                     'font-lock-comment-face)))) ))
> > > >
> > > > Notice that "M-q" performs paragraph filling for comments in C and other
> > > > languages.  It is not *auto* filling certainly, but it's very useful.
> > > >
> > > > I've found that to be the best myself.  That's because of commenting out
> > > > code.  The problem is if you comment out code then modify it when it's a
> > > > comment.  If you set Emacs to auto-fill comments, then it will auto-fill
> > > > those code comments as though they're text.  That's wrong when you want
> > > > to uncomment the block and make it back into code, it removes the
> > > > indentation.
> > > >
> > > > BR,
> > > > Robert Thorpe
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>

Re: Auto Fill Comments

[tomas]

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

On Thu, Nov 26, 2020 at 04:23:07PM +0100, Christopher Dimech wrote:
> I am getting somewhat confused because I have also seen
> people using set-fill-column and setq-default.
> 
> Is doing fill-column and set-fill-column the same thing?

It should. Do C-h f set-fill-column to get the details (if everything
else fails, read the instructions :)

I think set-fill-column is a wrapper around (setq fill-column <value>)
(which will set it buffer-local, see C-h v fill-column) to conveniently
bind it, as an interactive functn to C-x f.

The setq-default does something subtly different: it sets the variable's
default value, so its effect won't be buffer-local but global (for all
new buffers, which haven't a buffer local value set).

So if you want /all/ your buffers to have your value 72 (unless stated
otherwise specifically for your buffer), setq-default is your friend.

If you are targeting a specific buffer, use set-fill-column, or
do (setq fill-column <foo>), as you prefer.

Cheers
 - t

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

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Thursday, November 26, 2020 at 5:00 PM
> From: tomas@tuxteam.de
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: daniela-spit@gmx.it, help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Thu, Nov 26, 2020 at 04:23:07PM +0100, Christopher Dimech wrote:
> > I am getting somewhat confused because I have also seen
> > people using set-fill-column and setq-default.
> >
> > Is doing fill-column and set-fill-column the same thing?
>
> It should. Do C-h f set-fill-column to get the details (if everything
> else fails, read the instructions :)
>
> I think set-fill-column is a wrapper around (setq fill-column <value>)
> (which will set it buffer-local, see C-h v fill-column) to conveniently
> bind it, as an interactive functn to C-x f.
>
> The setq-default does something subtly different: it sets the variable's
> default value, so its effect won't be buffer-local but global (for all
> new buffers, which haven't a buffer local value set).
>
> So if you want /all/ your buffers to have your value 72 (unless stated
> otherwise specifically for your buffer), setq-default is your friend.

Does that mean that setq-default also enables automatic filling?

I need some explanation about setq, setq-default, and set-local.




> If you are targeting a specific buffer, use set-fill-column, or
> do (setq fill-column <foo>), as you prefer.
>
> Cheers
>  - t
>

Re: Auto Fill Comments

[daniela-spit]

> Sent: Thursday, November 26, 2020 at 6:22 PM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: tomas@tuxteam.de
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> > Sent: Thursday, November 26, 2020 at 5:00 PM
> > From: tomas@tuxteam.de
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: daniela-spit@gmx.it, help-gnu-emacs@gnu.org
> > Subject: Re: Auto Fill Comments
> >
> > On Thu, Nov 26, 2020 at 04:23:07PM +0100, Christopher Dimech wrote:
> > > I am getting somewhat confused because I have also seen
> > > people using set-fill-column and setq-default.
> > >
> > > Is doing fill-column and set-fill-column the same thing?
> >
> > It should. Do C-h f set-fill-column to get the details (if everything
> > else fails, read the instructions :)
> >
> > I think set-fill-column is a wrapper around (setq fill-column <value>)
> > (which will set it buffer-local, see C-h v fill-column) to conveniently
> > bind it, as an interactive functn to C-x f.
> >
> > The setq-default does something subtly different: it sets the variable's
> > default value, so its effect won't be buffer-local but global (for all
> > new buffers, which haven't a buffer local value set).
> >
> > So if you want /all/ your buffers to have your value 72 (unless stated
> > otherwise specifically for your buffer), setq-default is your friend.
>
> Does that mean that setq-default also enables automatic filling?
>
> I need some explanation about setq, setq-default, and setq-local.

My general impression that for fill-column to get effect,  you got to enable
auto-fill-mode first.

>
>
> > If you are targeting a specific buffer, use set-fill-column, or
> > do (setq fill-column <foo>), as you prefer.
> >
> > Cheers
> >  - t
> >
>
>

Re: Auto Fill Comments

[tomas]

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

On Thu, Nov 26, 2020 at 06:22:26PM +0100, Christopher Dimech wrote:

[...]

> Does that mean that setq-default also enables automatic filling?
> 
> I need some explanation about setq, setq-default, and set-local.

You should skim the manual's "Variables" section [1]

In a nutshell, variables are a way to attach a value to a
name. In Emacs, there are different kinds of variables.
For our current purposes, we consider global variables
and buffer-local variables (there are more!).

A global variable is seen from everywhere. If you set its
value while in buffer A, this change will be seen in every
other buffer.

Buffer-local variables can have one value per-buffer. It
shadows the global variable (if there's any with the same
name). Most mode things are buffer local. The `fill-column'
is one example. You might want different values for it
in different buffers (say, you're editing two sources with
different styles in one session), that's why it is set up
as a buffer-local variable.

So if you do (setq fill-column 72) in the context of buffer
A, only buffer A gets to see that.

Setq-local (not set-local, as you wrote) is just a convenience,
which makes the named variables buffer-local and sets their
values (thus leaving possibly like-named global variables
alone).

The setq-default is for setting one or more buffer-local
variables's default values.

The gory details are in the Elisp manual [3]. There's also
an explanation for setq-default which is much better than
I could come up with here.

Cheers

[1] Online here:
    For the user:
    https://www.gnu.org/software/emacs/manual/html_node/emacs/Variables.html#Variables
    For the lisp programmer:
    https://www.gnu.org/software/emacs/manual/html_node/elisp/Variables.html#Variables

    although you /should/ have those manuals with your Emacs installation.
    This is preferrable, since they should correspond to your Emacs
    version.

[2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer_002dLocal-Variables.html#Buffer_002dLocal-Variables

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

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Thursday, November 26, 2020 at 7:27 PM
> From: tomas@tuxteam.de
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Thu, Nov 26, 2020 at 06:22:26PM +0100, Christopher Dimech wrote:
>
> [...]
>
> > Does that mean that setq-default also enables automatic filling?
> >
> > I need some explanation about setq, setq-default, and set-local.
>
> You should skim the manual's "Variables" section [1]
>
> In a nutshell, variables are a way to attach a value to a
> name. In Emacs, there are different kinds of variables.
> For our current purposes, we consider global variables
> and buffer-local variables (there are more!).
>
> A global variable is seen from everywhere. If you set its
> value while in buffer A, this change will be seen in every
> other buffer.
>
> Buffer-local variables can have one value per-buffer. It
> shadows the global variable (if there's any with the same
> name). Most mode things are buffer local. The `fill-column'
> is one example. You might want different values for it
> in different buffers (say, you're editing two sources with
> different styles in one session), that's why it is set up
> as a buffer-local variable.
>
> So if you do (setq fill-column 72) in the context of buffer
> A, only buffer A gets to see that.

Had thought that setq was actually a global thing, not local.
For local variables I was using "let" and "let*", but that seems
a wrong understanding.


> Setq-local (not set-local, as you wrote) is just a convenience,
> which makes the named variables buffer-local and sets their
> values (thus leaving possibly like-named global variables
> alone).
>
> The setq-default is for setting one or more buffer-local
> variables's default values.
>
> The gory details are in the Elisp manual [3]. There's also
> an explanation for setq-default which is much better than
> I could come up with here.
>
> Cheers
>
> [1] Online here:
>     For the user:
>     https://www.gnu.org/software/emacs/manual/html_node/emacs/Variables.html#Variables
>     For the lisp programmer:
>     https://www.gnu.org/software/emacs/manual/html_node/elisp/Variables.html#Variables
>
>     although you /should/ have those manuals with your Emacs installation.
>     This is preferrable, since they should correspond to your Emacs
>     version.
>
> [2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer_002dLocal-Variables.html#Buffer_002dLocal-Variables
>

Re: Auto Fill Comments

[Christopher Dimech]

If I do  (setq comment-auto-fill-only-comments t) but then change my mind
and want to have auto fill for the whole buffer, what should I do?


> Sent: Thursday, November 26, 2020 at 7:44 PM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: tomas@tuxteam.de
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> > Sent: Thursday, November 26, 2020 at 7:27 PM
> > From: tomas@tuxteam.de
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: help-gnu-emacs@gnu.org
> > Subject: Re: Auto Fill Comments
> >
> > On Thu, Nov 26, 2020 at 06:22:26PM +0100, Christopher Dimech wrote:
> >
> > [...]
> >
> > > Does that mean that setq-default also enables automatic filling?
> > >
> > > I need some explanation about setq, setq-default, and set-local.
> >
> > You should skim the manual's "Variables" section [1]
> >
> > In a nutshell, variables are a way to attach a value to a
> > name. In Emacs, there are different kinds of variables.
> > For our current purposes, we consider global variables
> > and buffer-local variables (there are more!).
> >
> > A global variable is seen from everywhere. If you set its
> > value while in buffer A, this change will be seen in every
> > other buffer.
> >
> > Buffer-local variables can have one value per-buffer. It
> > shadows the global variable (if there's any with the same
> > name). Most mode things are buffer local. The `fill-column'
> > is one example. You might want different values for it
> > in different buffers (say, you're editing two sources with
> > different styles in one session), that's why it is set up
> > as a buffer-local variable.
> >
> > So if you do (setq fill-column 72) in the context of buffer
> > A, only buffer A gets to see that.
>
> Had thought that setq was actually a global thing, not local.
> For local variables I was using "let" and "let*", but that seems
> a wrong understanding.
>
>
> > Setq-local (not set-local, as you wrote) is just a convenience,
> > which makes the named variables buffer-local and sets their
> > values (thus leaving possibly like-named global variables
> > alone).
> >
> > The setq-default is for setting one or more buffer-local
> > variables's default values.
> >
> > The gory details are in the Elisp manual [3]. There's also
> > an explanation for setq-default which is much better than
> > I could come up with here.
> >
> > Cheers
> >
> > [1] Online here:
> >     For the user:
> >     https://www.gnu.org/software/emacs/manual/html_node/emacs/Variables.html#Variables
> >     For the lisp programmer:
> >     https://www.gnu.org/software/emacs/manual/html_node/elisp/Variables.html#Variables
> >
> >     although you /should/ have those manuals with your Emacs installation.
> >     This is preferrable, since they should correspond to your Emacs
> >     version.
> >
> > [2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer_002dLocal-Variables.html#Buffer_002dLocal-Variables
> >
>
>

Re: Auto Fill Comments

[tomas]

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

On Thu, Nov 26, 2020 at 07:44:10PM +0100, Christopher Dimech wrote:

[...]

> Had thought that setq was actually a global thing, not local.
> For local variables I was using "let" and "let*", but that seems
> a wrong understanding.

No, no. I was talking about buffer-local, i.e. bound to the
buffer. Your local is wrt. to the code (dynamic or lexical)

Buffer-local variables are global variables, as seen from the
code's perspective.

You didn't look at the docs, did you?

Cheers
 - t

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

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Thursday, November 26, 2020 at 9:16 PM
> From: tomas@tuxteam.de
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Thu, Nov 26, 2020 at 07:44:10PM +0100, Christopher Dimech wrote:
>
> [...]
>
> > Had thought that setq was actually a global thing, not local.
> > For local variables I was using "let" and "let*", but that seems
> > a wrong understanding.
>
> No, no. I was talking about buffer-local, i.e. bound to the
> buffer. Your local is wrt. to the code (dynamic or lexical)
>
> Buffer-local variables are global variables, as seen from the
> code's perspective.
>
> You didn't look at the docs, did you?

Was simply commenting.  When I started, I learned more from scrutinising
other's people's code.  The manual is hard for new users and there are
not many examples.  I am reading through the docs.

> Cheers
>  - t
>

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Thursday, November 26, 2020 at 9:16 PM
> From: tomas@tuxteam.de
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Thu, Nov 26, 2020 at 07:44:10PM +0100, Christopher Dimech wrote:
>
> [...]
>
> > Had thought that setq was actually a global thing, not local.
> > For local variables I was using "let" and "let*", but that seems
> > a wrong understanding.
>
> No, no. I was talking about buffer-local, i.e. bound to the
> buffer. Your local is wrt. to the code (dynamic or lexical)
>
> Buffer-local variables are global variables, as seen from the
> code's perspective.
>
> You didn't look at the docs, did you?

A problem with the docs is that it lists you so many different functions that
in some instances you are worse off than when you started.

> Cheers
>  - t
>

Re: Auto Fill Comments

[Christopher Dimech]

I have done as follows.  The problem started after reading that
for mode specific setup, comment-auto-fill-only-comments got to
be local


(setq-default fill-column 72)

(defun typh-auto-fill-mode (n)
   "Breaks lines at a specific number of columns using Auto Fill."
   (interactive "p")

   (if (= n 0) (turn-off-auto-fill))

   (if (= n 1)
      (progn
        (auto-fill-mode n)
        (setq comment-auto-fill-only-comments t) ))

   (if (= n 2)
      (progn
         (turn-on-auto-fill)
         (setq comment-auto-fill-only-comments nil) )))



> Sent: Thursday, November 26, 2020 at 9:16 PM
> From: tomas@tuxteam.de
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Thu, Nov 26, 2020 at 07:44:10PM +0100, Christopher Dimech wrote:
>
> [...]
>
> > Had thought that setq was actually a global thing, not local.
> > For local variables I was using "let" and "let*", but that seems
> > a wrong understanding.
>
> No, no. I was talking about buffer-local, i.e. bound to the
> buffer. Your local is wrt. to the code (dynamic or lexical)
>
> Buffer-local variables are global variables, as seen from the
> code's perspective.
>
> You didn't look at the docs, did you?
>
> Cheers
>  - t
>

RE: Auto Fill Comments

[Drew Adams]

> Had thought that setq was actually a global
> thing, not local. For local variables I was
> using "let" and "let*", but that seems a
> wrong understanding.

Please read the manual, node `Variables', as
Tomas advised.  But don't just skim it.  And
read its (5) subnodes.

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

As seems to be the case with many of your
questions, this is all explained clearly in
the Emacs doc.

There are local variables and ... local
variables.  Variables bound by `let',
`lambda', and named functions (formal
parameters) are typically local in more or
less the usual programming sense.

[But if such a variable is in fact defined
 as "special", or global if you prefer,
 then a `let' binding of it is "local" to
 the _duration_ of the `let' - the binding
 is _temporary_.  E.g., (defvar foo 42)
 followed by (let ((foo 24)) ...) may
 (depending on the context) bind global
 variable `foo' temporarily to 24.]

Buffer-local and file-local variables are
something else altogether.  They are global
variables that have a value that is specific
to - local in scope to - the current buffer
or file.  Some variables have a buffer-local
value in some buffers but only a global
value in other buffers (no buffer-local
value there).  Other variables are always
only buffer-local.

But again, don't listen to my explanation.
Consult the doc instead.  It's more exact,
more complete, and better presented
(clearer).

And when you've read what the Emacs manual
has to tell you about variables, consider
reading what the Elisp manual has to say
about variables.  There too, start with its
node `Variables', and move on to its (17!)
subnodes.

https://www.gnu.org/software/emacs/manual/html_node/elisp/Variables.html

You don't do yourself any favors, or
encourage help in forums such as this, by
not trying to make use of the doc.

The doc is the result of years of effort
and collaboration, taking into account
tons of feedback by users of all sorts.
You're not special - try benefitting from
the efforts of those who've gone before.
THEN, if you have a question, please do
ask it.

HTH.

Re: RE: Auto Fill Comments

[Christopher Dimech]

The manuals should be rewritten because they are incomprehensible.
Perhaps it was good in the eighties.  It continues forever.  Consider
"face customisation" for instance, which just means font.  Nobody
fuckin reads a manual with 17 nodes.  You don't know which one to use,
which commands are most useful, and so on.  The problem gets compounded
because every esoteric command is there.

You are just insisting on something bad and inefficient.


---------------------
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: Thursday, November 26, 2020 at 10:51 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>, tomas@tuxteam.de
> Cc: help-gnu-emacs@gnu.org
> Subject: RE: Auto Fill Comments
>
> > Had thought that setq was actually a global
> > thing, not local. For local variables I was
> > using "let" and "let*", but that seems a
> > wrong understanding.
>
> Please read the manual, node `Variables', as
> Tomas advised.  But don't just skim it.  And
> read its (5) subnodes.
>
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Variables.html
>
> As seems to be the case with many of your
> questions, this is all explained clearly in
> the Emacs doc.
>
> There are local variables and ... local
> variables.  Variables bound by `let',
> `lambda', and named functions (formal
> parameters) are typically local in more or
> less the usual programming sense.
>
> [But if such a variable is in fact defined
>  as "special", or global if you prefer,
>  then a `let' binding of it is "local" to
>  the _duration_ of the `let' - the binding
>  is _temporary_.  E.g., (defvar foo 42)
>  followed by (let ((foo 24)) ...) may
>  (depending on the context) bind global
>  variable `foo' temporarily to 24.]
>
> Buffer-local and file-local variables are
> something else altogether.  They are global
> variables that have a value that is specific
> to - local in scope to - the current buffer
> or file.  Some variables have a buffer-local
> value in some buffers but only a global
> value in other buffers (no buffer-local
> value there).  Other variables are always
> only buffer-local.
>
> But again, don't listen to my explanation.
> Consult the doc instead.  It's more exact,
> more complete, and better presented
> (clearer).
>
> And when you've read what the Emacs manual
> has to tell you about variables, consider
> reading what the Elisp manual has to say
> about variables.  There too, start with its
> node `Variables', and move on to its (17!)
> subnodes.
>
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Variables.html
>
> You don't do yourself any favors, or
> encourage help in forums such as this, by
> not trying to make use of the doc.
>
> The doc is the result of years of effort
> and collaboration, taking into account
> tons of feedback by users of all sorts.
> You're not special - try benefitting from
> the efforts of those who've gone before.
> THEN, if you have a question, please do
> ask it.
>
> HTH.
>

RE: RE: Auto Fill Comments

[arthur miller]

Yes, Emacs terminology is old. I dislike killing stuff, reminds me of war, I never heard  word yank before I start using and font locking sounds like I am in a prison. But if you can go past few names, Emacs is quite useful piece of software. Probably the most advanced terminal emulator I have ever used, and it even has a text editor built in.

And nowadays it can swap more than 8 meg of ram too!


-------- Originalmeddelande --------
Från: Christopher Dimech <dimech@gmx.com>
Datum: 2020-11-27 01:48 (GMT+01:00)
Till: Drew Adams <drew.adams@oracle.com>
Kopia: help-gnu-emacs@gnu.org
Ämne: Re: RE: Auto Fill Comments

The manuals should be rewritten because they are incomprehensible.
Perhaps it was good in the eighties.  It continues forever.  Consider
"face customisation" for instance, which just means font.  Nobody
fuckin reads a manual with 17 nodes.  You don't know which one to use,
which commands are most useful, and so on.  The problem gets compounded
because every esoteric command is there.

You are just insisting on something bad and inefficient.


---------------------
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: Thursday, November 26, 2020 at 10:51 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>, tomas@tuxteam.de
> Cc: help-gnu-emacs@gnu.org
> Subject: RE: Auto Fill Comments
>
> > Had thought that setq was actually a global
> > thing, not local. For local variables I was
> > using "let" and "let*", but that seems a
> > wrong understanding.
>
> Please read the manual, node `Variables', as
> Tomas advised.  But don't just skim it.  And
> read its (5) subnodes.
>
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Variables.html
>
> As seems to be the case with many of your
> questions, this is all explained clearly in
> the Emacs doc.
>
> There are local variables and ... local
> variables.  Variables bound by `let',
> `lambda', and named functions (formal
> parameters) are typically local in more or
> less the usual programming sense.
>
> [But if such a variable is in fact defined
>  as "special", or global if you prefer,
>  then a `let' binding of it is "local" to
>  the _duration_ of the `let' - the binding
>  is _temporary_.  E.g., (defvar foo 42)
>  followed by (let ((foo 24)) ...) may
>  (depending on the context) bind global
>  variable `foo' temporarily to 24.]
>
> Buffer-local and file-local variables are
> something else altogether.  They are global
> variables that have a value that is specific
> to - local in scope to - the current buffer
> or file.  Some variables have a buffer-local
> value in some buffers but only a global
> value in other buffers (no buffer-local
> value there).  Other variables are always
> only buffer-local.
>
> But again, don't listen to my explanation.
> Consult the doc instead.  It's more exact,
> more complete, and better presented
> (clearer).
>
> And when you've read what the Emacs manual
> has to tell you about variables, consider
> reading what the Elisp manual has to say
> about variables.  There too, start with its
> node `Variables', and move on to its (17!)
> subnodes.
>
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Variables.html
>
> You don't do yourself any favors, or
> encourage help in forums such as this, by
> not trying to make use of the doc.
>
> The doc is the result of years of effort
> and collaboration, taking into account
> tons of feedback by users of all sorts.
> You're not special - try benefitting from
> the efforts of those who've gone before.
> THEN, if you have a question, please do
> ask it.
>
> HTH.
>

Re: RE: RE: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 2:57 AM
> From: "arthur miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>, "Drew Adams" <drew.adams@oracle.com>
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> Subject: RE: RE: Auto Fill Comments
>
> Yes, Emacs terminology is old. I dislike killing stuff, reminds me of war, I never heard  word yank before I start using and font locking sounds like I am in a prison. But if you can go past few names, Emacs is quite useful piece of software. Probably the most advanced terminal emulator I have ever used, and it even has a text editor built in.

Sure, I spend much of my time in emacs.  But there is much more work to do on it
to became really good and quick to code in elisp,

> And nowadays it can swap more than 8 meg of ram too!
> 
> 
> -------- Originalmeddelande --------
> Från: Christopher Dimech <dimech@gmx.com>
> Datum: 2020-11-27 01:48 (GMT+01:00)
> Till: Drew Adams <drew.adams@oracle.com>
> Kopia: help-gnu-emacs@gnu.org
> Ämne: Re: RE: Auto Fill Comments
> 
> The manuals should be rewritten because they are incomprehensible.
> Perhaps it was good in the eighties.  It continues forever.  Consider
> "face customisation" for instance, which just means font.  Nobody
> fuckin reads a manual with 17 nodes.  You don't know which one to use,
> which commands are most useful, and so on.  The problem gets compounded
> because every esoteric command is there.
> 
> You are just insisting on something bad and inefficient.
> 
> 
> ---------------------
> 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: Thursday, November 26, 2020 at 10:51 PM
> > From: "Drew Adams" <drew.adams@oracle.com>
> > To: "Christopher Dimech" <dimech@gmx.com>, tomas@tuxteam.de
> > Cc: help-gnu-emacs@gnu.org
> > Subject: RE: Auto Fill Comments
> >
> > > Had thought that setq was actually a global
> > > thing, not local. For local variables I was
> > > using "let" and "let*", but that seems a
> > > wrong understanding.
> >
> > Please read the manual, node `Variables', as
> > Tomas advised.  But don't just skim it.  And
> > read its (5) subnodes.
> >
> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Variables.html
> >
> > As seems to be the case with many of your
> > questions, this is all explained clearly in
> > the Emacs doc.
> >
> > There are local variables and ... local
> > variables.  Variables bound by `let',
> > `lambda', and named functions (formal
> > parameters) are typically local in more or
> > less the usual programming sense.
> >
> > [But if such a variable is in fact defined
> >  as "special", or global if you prefer,
> >  then a `let' binding of it is "local" to
> >  the _duration_ of the `let' - the binding
> >  is _temporary_.  E.g., (defvar foo 42)
> >  followed by (let ((foo 24)) ...) may
> >  (depending on the context) bind global
> >  variable `foo' temporarily to 24.]
> >
> > Buffer-local and file-local variables are
> > something else altogether.  They are global
> > variables that have a value that is specific
> > to - local in scope to - the current buffer
> > or file.  Some variables have a buffer-local
> > value in some buffers but only a global
> > value in other buffers (no buffer-local
> > value there).  Other variables are always
> > only buffer-local.
> >
> > But again, don't listen to my explanation.
> > Consult the doc instead.  It's more exact,
> > more complete, and better presented
> > (clearer).
> >
> > And when you've read what the Emacs manual
> > has to tell you about variables, consider
> > reading what the Elisp manual has to say
> > about variables.  There too, start with its
> > node `Variables', and move on to its (17!)
> > subnodes.
> >
> > https://www.gnu.org/software/emacs/manual/html_node/elisp/Variables.html
> >
> > You don't do yourself any favors, or
> > encourage help in forums such as this, by
> > not trying to make use of the doc.
> >
> > The doc is the result of years of effort
> > and collaboration, taking into account
> > tons of feedback by users of all sorts.
> > You're not special - try benefitting from
> > the efforts of those who've gone before.
> > THEN, if you have a question, please do
> > ask it.
> >
> > HTH.
> >
> 
>

RE: RE: RE: Auto Fill Comments

[arthur miller]

Well, you are welcome to contribute and make Emacs the best application in the world.



-------- Originalmeddelande --------
Från: Christopher Dimech <dimech@gmx.com>
Datum: 2020-11-27 03:20 (GMT+01:00)
Till: arthur miller <arthur.miller@live.com>
Kopia: Drew Adams <drew.adams@oracle.com>, help-gnu-emacs@gnu.org
Ämne: Re: RE: RE: Auto Fill Comments

> Sent: Friday, November 27, 2020 at 2:57 AM
> From: "arthur miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>, "Drew Adams" <drew.adams@oracle.com>
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> Subject: RE: RE: Auto Fill Comments
>
> Yes, Emacs terminology is old. I dislike killing stuff, reminds me of war, I never heard  word yank before I start using and font locking sounds like I am in a prison. But if you can go past few names, Emacs is quite useful piece of software. Probably the most advanced terminal emulator I have ever used, and it even has a text editor built in.

Sure, I spend much of my time in emacs.  But there is much more work to do on it
to became really good and quick to code in elisp,

> And nowadays it can swap more than 8 meg of ram too!
>
>
> -------- Originalmeddelande --------
> Från: Christopher Dimech <dimech@gmx.com>
> Datum: 2020-11-27 01:48 (GMT+01:00)
> Till: Drew Adams <drew.adams@oracle.com>
> Kopia: help-gnu-emacs@gnu.org
> Ämne: Re: RE: Auto Fill Comments
>
> The manuals should be rewritten because they are incomprehensible.
> Perhaps it was good in the eighties.  It continues forever.  Consider
> "face customisation" for instance, which just means font.  Nobody
> fuckin reads a manual with 17 nodes.  You don't know which one to use,
> which commands are most useful, and so on.  The problem gets compounded
> because every esoteric command is there.
>
> You are just insisting on something bad and inefficient.
>
>
> ---------------------
> 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: Thursday, November 26, 2020 at 10:51 PM
> > From: "Drew Adams" <drew.adams@oracle.com>
> > To: "Christopher Dimech" <dimech@gmx.com>, tomas@tuxteam.de
> > Cc: help-gnu-emacs@gnu.org
> > Subject: RE: Auto Fill Comments
> >
> > > Had thought that setq was actually a global
> > > thing, not local. For local variables I was
> > > using "let" and "let*", but that seems a
> > > wrong understanding.
> >
> > Please read the manual, node `Variables', as
> > Tomas advised.  But don't just skim it.  And
> > read its (5) subnodes.
> >
> > https://www.gnu.org/software/emacs/manual/html_node/emacs/Variables.html
> >
> > As seems to be the case with many of your
> > questions, this is all explained clearly in
> > the Emacs doc.
> >
> > There are local variables and ... local
> > variables.  Variables bound by `let',
> > `lambda', and named functions (formal
> > parameters) are typically local in more or
> > less the usual programming sense.
> >
> > [But if such a variable is in fact defined
> >  as "special", or global if you prefer,
> >  then a `let' binding of it is "local" to
> >  the _duration_ of the `let' - the binding
> >  is _temporary_.  E.g., (defvar foo 42)
> >  followed by (let ((foo 24)) ...) may
> >  (depending on the context) bind global
> >  variable `foo' temporarily to 24.]
> >
> > Buffer-local and file-local variables are
> > something else altogether.  They are global
> > variables that have a value that is specific
> > to - local in scope to - the current buffer
> > or file.  Some variables have a buffer-local
> > value in some buffers but only a global
> > value in other buffers (no buffer-local
> > value there).  Other variables are always
> > only buffer-local.
> >
> > But again, don't listen to my explanation.
> > Consult the doc instead.  It's more exact,
> > more complete, and better presented
> > (clearer).
> >
> > And when you've read what the Emacs manual
> > has to tell you about variables, consider
> > reading what the Elisp manual has to say
> > about variables.  There too, start with its
> > node `Variables', and move on to its (17!)
> > subnodes.
> >
> > https://www.gnu.org/software/emacs/manual/html_node/elisp/Variables.html
> >
> > You don't do yourself any favors, or
> > encourage help in forums such as this, by
> > not trying to make use of the doc.
> >
> > The doc is the result of years of effort
> > and collaboration, taking into account
> > tons of feedback by users of all sorts.
> > You're not special - try benefitting from
> > the efforts of those who've gone before.
> > THEN, if you have a question, please do
> > ask it.
> >
> > HTH.
> >
>
>

Re: RE: RE: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-11-27 05:22]:
> > Sent: Friday, November 27, 2020 at 2:57 AM
> > From: "arthur miller" <arthur.miller@live.com>
> > To: "Christopher Dimech" <dimech@gmx.com>, "Drew Adams" <drew.adams@oracle.com>
> > Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> > Subject: RE: RE: Auto Fill Comments
> >
> > Yes, Emacs terminology is old.

It may be old but not obsolete. You may be younger than Emacs and you
encounter things that were already there before you, but need not be
obsolete.

> I dislike killing stuff, reminds me > of war, I never heard word
> yank before I start using and font > locking sounds like I am in a
> prison. But if you can go past few > names, Emacs is quite useful
> piece of software. Probably the most > advanced terminal emulator I
> have ever used, and it even has a > text editor built in.

Words cannot and should not be chosen in the manner not to affect each
person. There is subset of words we name vulgar or obscene and they
are such because people agree to be so and that such should not be
used. Yet there is literature where such words are appropriate on the
right place.

One reader can despise word A, other word B, other word C, other word
D, and then in the end, if one should follow that principle then
better not write at all! There is no logic in trying to accommodate
every person's traumatic experiences.

What does make sense to help in understanding is using dictionaries
and finding definitions.

Here I just pulled the definition of the noun "kill" and verb "kill"
from the Wordnet dictionary:

The noun does not apply in the Emacs context as it is not verb. But
even the noun here shows that "killing" may be used in the sense of
very large profit. See:
https://idioms.thefreedictionary.com/make+a+killing

The word in itself is harmless. Trauma that person associates with the
word is what hurts the person. To lessen that effect it is advisable
to find the true meanings of the words used and in which context as
that way one will not use the imaginative meanings or wrong meanings
that stem from person's mind.

* Overview of noun killing

The noun killing has 3 senses (first 2 from tagged texts)
1. (5) killing, violent death -- (an event that causes someone to die)
2. (5) killing, kill, putting to death -- (the act of terminating a life)
3. killing, cleanup -- (a very large profit)

Not even English speaking people will know that the verb "kill" has
this many senses. One can see that definition number 12 applies here:

12. kill, obliterate, wipe out -- (mark for deletion, rub off, or
erase; "kill these lines in the President's speech")

Thus the verb "to kill" is part of English language. If person is not
English speaker or does not find proper definitions of course that
most used definition will be used. If you find yourself having
troubles or you find something not logical, please open up dictionary
and look up definitions.

One can see in the below examples that there are other valid uses of
the word "kill" in various senses.

* Overview of verb kill

The verb kill has 15 senses (first 3 from tagged texts)
1. (103) kill -- (cause to die; put to death, usually intentionally or knowingly; "This man killed several people when he tried to rob a bank"; "The farmer killed a pig for the holidays")
2. (1) kill, shoot down, defeat, vote down, vote out -- (thwart the passage of; "kill a motion"; "he shot down the student's proposal")
3. (1) stamp out, kill -- (end or extinguish by forceful means; "Stamp out poverty!")
4. kill -- (be fatal; "cigarettes kill"; "drunken driving kills")
5. kill -- (be the source of great pain for; "These new shoes are killing me!")
6. kill -- (overwhelm with hilarity, pleasure, or admiration; "The comedian was so funny, he was killing me!")
7. kill -- (hit with so much force as to make a return impossible, in racket games; "She killed the ball")
8. kill -- (hit with great force; "He killed the ball")
9. kill -- (deprive of life; "AIDS has killed thousands in Africa")
10. kill -- (cause the death of, without intention; "She was killed in the collision of three cars")
11. toss off, pop, bolt down, belt down, pour down, down, drink down, kill -- (drink down entirely; "He downed three martinis before dinner"; "She killed a bottle of brandy that night"; "They popped a few beer after work")
12. kill, obliterate, wipe out -- (mark for deletion, rub off, or erase; "kill these lines in the President's speech")
13. kill -- (tire out completely; "The daily stress of her work is killing her")
14. kill -- (cause to cease operating; "kill the engine")
15. kill -- (destroy a vitally essential quality of or in; "Eating artichokes kills the taste of all other foods")

Re: Auto Fill Comments

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Christopher Dimech <dimech@gmx.com> [2020-11-27 05:22]:
>> > Sent: Friday, November 27, 2020 at 2:57 AM
>> > From: "arthur miller" <arthur.miller@live.com>
>> > To: "Christopher Dimech" <dimech@gmx.com>, "Drew Adams" <drew.adams@oracle.com>
>> > Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
>> > Subject: RE: RE: Auto Fill Comments
>> >
>> > Yes, Emacs terminology is old.
>
> It may be old but not obsolete. You may be younger than Emacs and you
> encounter things that were already there before you, but need not be
> obsolete.
>
>> I dislike killing stuff, reminds me > of war, I never heard word
>> yank before I start using and font > locking sounds like I am in a
>> prison. But if you can go past few > names, Emacs is quite useful
>> piece of software. Probably the most > advanced terminal emulator I
>> have ever used, and it even has a > text editor built in.
>
> Words cannot and should not be chosen in the manner not to affect each
> person. There is subset of words we name vulgar or obscene and they
> are such because people agree to be so and that such should not be
> used. Yet there is literature where such words are appropriate on the
> right place.
>
> One reader can despise word A, other word B, other word C, other word
> D, and then in the end, if one should follow that principle then
> better not write at all! There is no logic in trying to accommodate
> every person's traumatic experiences.
>
> What does make sense to help in understanding is using dictionaries
> and finding definitions.
>
> Here I just pulled the definition of the noun "kill" and verb "kill"
> from the Wordnet dictionary:
>
> The noun does not apply in the Emacs context as it is not verb. But
> even the noun here shows that "killing" may be used in the sense of
> very large profit. See:
> https://idioms.thefreedictionary.com/make+a+killing
>
> The word in itself is harmless. Trauma that person associates with the
> word is what hurts the person. To lessen that effect it is advisable
> to find the true meanings of the words used and in which context as
> that way one will not use the imaginative meanings or wrong meanings
> that stem from person's mind.
>
> * Overview of noun killing
>
> The noun killing has 3 senses (first 2 from tagged texts)
> 1. (5) killing, violent death -- (an event that causes someone to die)
> 2. (5) killing, kill, putting to death -- (the act of terminating a life)
> 3. killing, cleanup -- (a very large profit)
>
> Not even English speaking people will know that the verb "kill" has
> this many senses. One can see that definition number 12 applies here:
>
> 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or
> erase; "kill these lines in the President's speech")
>
> Thus the verb "to kill" is part of English language. If person is not
> English speaker or does not find proper definitions of course that
> most used definition will be used. If you find yourself having
> troubles or you find something not logical, please open up dictionary
> and look up definitions.
>
> One can see in the below examples that there are other valid uses of
> the word "kill" in various senses.
>
> * Overview of verb kill
>
> The verb kill has 15 senses (first 3 from tagged texts)
> 1. (103) kill -- (cause to die; put to death, usually intentionally or
> knowingly; "This man killed several people when he tried to rob a bank"; "The
> farmer killed a pig for the holidays")
> 2. (1) kill, shoot down, defeat, vote down, vote out -- (thwart the passage of; "kill a motion"; "he shot down the student's proposal")
> 3. (1) stamp out, kill -- (end or extinguish by forceful means; "Stamp out poverty!")
> 4. kill -- (be fatal; "cigarettes kill"; "drunken driving kills")
> 5. kill -- (be the source of great pain for; "These new shoes are killing me!")
> 6. kill -- (overwhelm with hilarity, pleasure, or admiration; "The comedian was so funny, he was killing me!")
> 7. kill -- (hit with so much force as to make a return impossible, in racket games; "She killed the ball")
> 8. kill -- (hit with great force; "He killed the ball")
> 9. kill -- (deprive of life; "AIDS has killed thousands in Africa")
> 10. kill -- (cause the death of, without intention; "She was killed in the collision of three cars")
> 11. toss off, pop, bolt down, belt down, pour down, down, drink down, kill --
> (drink down entirely; "He downed three martinis before dinner"; "She killed a
> bottle of brandy that night"; "They popped a few beer after work")
> 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or erase; "kill these lines in the President's speech")
> 13. kill -- (tire out completely; "The daily stress of her work is killing her")
> 14. kill -- (cause to cease operating; "kill the engine")
> 15. kill -- (destroy a vitally essential quality of or in; "Eating artichokes kills the taste of all other foods")

> What does make sense to help in understanding is using dictionaries
> and finding definitions.
Indeed; my engish really sux I know! Thank your posting the meaning of
world kill, being long time until I worked on my glossary. 

Frankly I said old; I didn't said obsolete; nor incomprehensive;
on contrary. Didn't you read that from the message I tried to convey?

I think you are going into waters we don't need to go to here. I was
illustrating to the guy that everybody can find things to disslike, but
at the end terminology is just names, just a combination of characters
or sounds not to get attached to.

> If you find yourself having
> troubles or you find something not logical, please open up dictionary
> and look up definitions.

> The word in itself is harmless. Trauma that person associates with the
> word is what hurts the person. To lessen that effect it is advisable
> to find the true meanings of the words used and in which context as
> that way one will not use the imaginative meanings or wrong meanings
> that stem from person's mind.
For the record; I have no traumas, and if I did I would certainly not
ask for the advice on the Internet but I can't be not to comment your
statements: 

Do you mean, when people have traumas, they should get a dictionary to
read, to make them feel better? Because that is what you are saying! :D
Is that seriously what you are claiming, or you are just trying to be
ironic/sarcastic?

If that is so, then I hope you are not working as a psychiatrist. That
sounds a little bit odd if you believe that people have traumas because
they got wrong meaning of a word. I would rather claim the
opposite. Also saying people use imaginative meanings is quite a wild
claim; that is somethign you would have to assert on per case basis.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 7:27 AM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Jean Louis" <bugs@gnu.support>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> Subject: Re: Auto Fill Comments
>
> Jean Louis <bugs@gnu.support> writes:
>
> > * Christopher Dimech <dimech@gmx.com> [2020-11-27 05:22]:
> >> > Sent: Friday, November 27, 2020 at 2:57 AM
> >> > From: "arthur miller" <arthur.miller@live.com>
> >> > To: "Christopher Dimech" <dimech@gmx.com>, "Drew Adams" <drew.adams@oracle.com>
> >> > Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> >> > Subject: RE: RE: Auto Fill Comments
> >> >
> >> > Yes, Emacs terminology is old.
> >
> > It may be old but not obsolete. You may be younger than Emacs and you
> > encounter things that were already there before you, but need not be
> > obsolete.
> >
> >> I dislike killing stuff, reminds me > of war, I never heard word
> >> yank before I start using and font > locking sounds like I am in a
> >> prison. But if you can go past few > names, Emacs is quite useful
> >> piece of software. Probably the most > advanced terminal emulator I
> >> have ever used, and it even has a > text editor built in.
> >
> > Words cannot and should not be chosen in the manner not to affect each
> > person. There is subset of words we name vulgar or obscene and they
> > are such because people agree to be so and that such should not be
> > used. Yet there is literature where such words are appropriate on the
> > right place.
> >
> > One reader can despise word A, other word B, other word C, other word
> > D, and then in the end, if one should follow that principle then
> > better not write at all! There is no logic in trying to accommodate
> > every person's traumatic experiences.
> >
> > What does make sense to help in understanding is using dictionaries
> > and finding definitions.
> >
> > Here I just pulled the definition of the noun "kill" and verb "kill"
> > from the Wordnet dictionary:
> >
> > The noun does not apply in the Emacs context as it is not verb. But
> > even the noun here shows that "killing" may be used in the sense of
> > very large profit. See:
> > https://idioms.thefreedictionary.com/make+a+killing
> >
> > The word in itself is harmless. Trauma that person associates with the
> > word is what hurts the person. To lessen that effect it is advisable
> > to find the true meanings of the words used and in which context as
> > that way one will not use the imaginative meanings or wrong meanings
> > that stem from person's mind.
> >
> > * Overview of noun killing
> >
> > The noun killing has 3 senses (first 2 from tagged texts)
> > 1. (5) killing, violent death -- (an event that causes someone to die)
> > 2. (5) killing, kill, putting to death -- (the act of terminating a life)
> > 3. killing, cleanup -- (a very large profit)
> >
> > Not even English speaking people will know that the verb "kill" has
> > this many senses. One can see that definition number 12 applies here:
> >
> > 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or
> > erase; "kill these lines in the President's speech")
> >
> > Thus the verb "to kill" is part of English language. If person is not
> > English speaker or does not find proper definitions of course that
> > most used definition will be used. If you find yourself having
> > troubles or you find something not logical, please open up dictionary
> > and look up definitions.
> >
> > One can see in the below examples that there are other valid uses of
> > the word "kill" in various senses.
> >
> > * Overview of verb kill
> >
> > The verb kill has 15 senses (first 3 from tagged texts)
> > 1. (103) kill -- (cause to die; put to death, usually intentionally or
> > knowingly; "This man killed several people when he tried to rob a bank"; "The
> > farmer killed a pig for the holidays")
> > 2. (1) kill, shoot down, defeat, vote down, vote out -- (thwart the passage of; "kill a motion"; "he shot down the student's proposal")
> > 3. (1) stamp out, kill -- (end or extinguish by forceful means; "Stamp out poverty!")
> > 4. kill -- (be fatal; "cigarettes kill"; "drunken driving kills")
> > 5. kill -- (be the source of great pain for; "These new shoes are killing me!")
> > 6. kill -- (overwhelm with hilarity, pleasure, or admiration; "The comedian was so funny, he was killing me!")
> > 7. kill -- (hit with so much force as to make a return impossible, in racket games; "She killed the ball")
> > 8. kill -- (hit with great force; "He killed the ball")
> > 9. kill -- (deprive of life; "AIDS has killed thousands in Africa")
> > 10. kill -- (cause the death of, without intention; "She was killed in the collision of three cars")
> > 11. toss off, pop, bolt down, belt down, pour down, down, drink down, kill --
> > (drink down entirely; "He downed three martinis before dinner"; "She killed a
> > bottle of brandy that night"; "They popped a few beer after work")
> > 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or erase; "kill these lines in the President's speech")
> > 13. kill -- (tire out completely; "The daily stress of her work is killing her")
> > 14. kill -- (cause to cease operating; "kill the engine")
> > 15. kill -- (destroy a vitally essential quality of or in; "Eating artichokes kills the taste of all other foods")
>
> > What does make sense to help in understanding is using dictionaries
> > and finding definitions.
> Indeed; my engish really sux I know! Thank your posting the meaning of
> world kill, being long time until I worked on my glossary.
>
> Frankly I said old; I didn't said obsolete; nor incomprehensive;
> on contrary. Didn't you read that from the message I tried to convey?
>
> I think you are going into waters we don't need to go to here. I was
> illustrating to the guy that everybody can find things to disslike, but
> at the end terminology is just names, just a combination of characters
> or sounds not to get attached to.
>
> > If you find yourself having
> > troubles or you find something not logical, please open up dictionary
> > and look up definitions.
>
> > The word in itself is harmless. Trauma that person associates with the
> > word is what hurts the person. To lessen that effect it is advisable
> > to find the true meanings of the words used and in which context as
> > that way one will not use the imaginative meanings or wrong meanings
> > that stem from person's mind.
> For the record; I have no traumas, and if I did I would certainly not
> ask for the advice on the Internet but I can't be not to comment your
> statements:
>
> Do you mean, when people have traumas, they should get a dictionary to
> read, to make them feel better? Because that is what you are saying! :D
> Is that seriously what you are claiming, or you are just trying to be
> ironic/sarcastic?
>
> If that is so, then I hope you are not working as a psychiatrist. That
> sounds a little bit odd if you believe that people have traumas because
> they got wrong meaning of a word. I would rather claim the
> opposite. Also saying people use imaginative meanings is quite a wild
> claim; that is somethign you would have to assert on per case basis.

The last time I had trauma, it was from ringing my head after hitting a glass door.
I absolutely did not see the door.  Why do people have to clean so good!

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Friday, November 27, 2020 at 7:27 AM
>> From: "Arthur Miller" <arthur.miller@live.com>
>> To: "Jean Louis" <bugs@gnu.support>
>> Cc: "Christopher Dimech" <dimech@gmx.com>, "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
>> Subject: Re: Auto Fill Comments
>>
>> Jean Louis <bugs@gnu.support> writes:
>>
>> > * Christopher Dimech <dimech@gmx.com> [2020-11-27 05:22]:
>> >> > Sent: Friday, November 27, 2020 at 2:57 AM
>> >> > From: "arthur miller" <arthur.miller@live.com>
>> >> > To: "Christopher Dimech" <dimech@gmx.com>, "Drew Adams" <drew.adams@oracle.com>
>> >> > Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
>> >> > Subject: RE: RE: Auto Fill Comments
>> >> >
>> >> > Yes, Emacs terminology is old.
>> >
>> > It may be old but not obsolete. You may be younger than Emacs and you
>> > encounter things that were already there before you, but need not be
>> > obsolete.
>> >
>> >> I dislike killing stuff, reminds me > of war, I never heard word
>> >> yank before I start using and font > locking sounds like I am in a
>> >> prison. But if you can go past few > names, Emacs is quite useful
>> >> piece of software. Probably the most > advanced terminal emulator I
>> >> have ever used, and it even has a > text editor built in.
>> >
>> > Words cannot and should not be chosen in the manner not to affect each
>> > person. There is subset of words we name vulgar or obscene and they
>> > are such because people agree to be so and that such should not be
>> > used. Yet there is literature where such words are appropriate on the
>> > right place.
>> >
>> > One reader can despise word A, other word B, other word C, other word
>> > D, and then in the end, if one should follow that principle then
>> > better not write at all! There is no logic in trying to accommodate
>> > every person's traumatic experiences.
>> >
>> > What does make sense to help in understanding is using dictionaries
>> > and finding definitions.
>> >
>> > Here I just pulled the definition of the noun "kill" and verb "kill"
>> > from the Wordnet dictionary:
>> >
>> > The noun does not apply in the Emacs context as it is not verb. But
>> > even the noun here shows that "killing" may be used in the sense of
>> > very large profit. See:
>> > https://idioms.thefreedictionary.com/make+a+killing
>> >
>> > The word in itself is harmless. Trauma that person associates with the
>> > word is what hurts the person. To lessen that effect it is advisable
>> > to find the true meanings of the words used and in which context as
>> > that way one will not use the imaginative meanings or wrong meanings
>> > that stem from person's mind.
>> >
>> > * Overview of noun killing
>> >
>> > The noun killing has 3 senses (first 2 from tagged texts)
>> > 1. (5) killing, violent death -- (an event that causes someone to die)
>> > 2. (5) killing, kill, putting to death -- (the act of terminating a life)
>> > 3. killing, cleanup -- (a very large profit)
>> >
>> > Not even English speaking people will know that the verb "kill" has
>> > this many senses. One can see that definition number 12 applies here:
>> >
>> > 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or
>> > erase; "kill these lines in the President's speech")
>> >
>> > Thus the verb "to kill" is part of English language. If person is not
>> > English speaker or does not find proper definitions of course that
>> > most used definition will be used. If you find yourself having
>> > troubles or you find something not logical, please open up dictionary
>> > and look up definitions.
>> >
>> > One can see in the below examples that there are other valid uses of
>> > the word "kill" in various senses.
>> >
>> > * Overview of verb kill
>> >
>> > The verb kill has 15 senses (first 3 from tagged texts)
>> > 1. (103) kill -- (cause to die; put to death, usually intentionally or
>> > knowingly; "This man killed several people when he tried to rob a bank"; "The
>> > farmer killed a pig for the holidays")
>> > 2. (1) kill, shoot down, defeat, vote down, vote out -- (thwart the passage of; "kill a motion"; "he shot down the student's proposal")
>> > 3. (1) stamp out, kill -- (end or extinguish by forceful means; "Stamp out poverty!")
>> > 4. kill -- (be fatal; "cigarettes kill"; "drunken driving kills")
>> > 5. kill -- (be the source of great pain for; "These new shoes are killing me!")
>> > 6. kill -- (overwhelm with hilarity, pleasure, or admiration; "The comedian was so funny, he was killing me!")
>> > 7. kill -- (hit with so much force as to make a return impossible, in racket games; "She killed the ball")
>> > 8. kill -- (hit with great force; "He killed the ball")
>> > 9. kill -- (deprive of life; "AIDS has killed thousands in Africa")
>> > 10. kill -- (cause the death of, without intention; "She was killed in the collision of three cars")
>> > 11. toss off, pop, bolt down, belt down, pour down, down, drink down, kill --
>> > (drink down entirely; "He downed three martinis before dinner"; "She killed a
>> > bottle of brandy that night"; "They popped a few beer after work")
>> > 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or erase; "kill these lines in the President's speech")
>> > 13. kill -- (tire out completely; "The daily stress of her work is killing her")
>> > 14. kill -- (cause to cease operating; "kill the engine")
>> > 15. kill -- (destroy a vitally essential quality of or in; "Eating artichokes kills the taste of all other foods")
>>
>> > What does make sense to help in understanding is using dictionaries
>> > and finding definitions.
>> Indeed; my engish really sux I know! Thank your posting the meaning of
>> world kill, being long time until I worked on my glossary.
>>
>> Frankly I said old; I didn't said obsolete; nor incomprehensive;
>> on contrary. Didn't you read that from the message I tried to convey?
>>
>> I think you are going into waters we don't need to go to here. I was
>> illustrating to the guy that everybody can find things to disslike, but
>> at the end terminology is just names, just a combination of characters
>> or sounds not to get attached to.
>>
>> > If you find yourself having
>> > troubles or you find something not logical, please open up dictionary
>> > and look up definitions.
>>
>> > The word in itself is harmless. Trauma that person associates with the
>> > word is what hurts the person. To lessen that effect it is advisable
>> > to find the true meanings of the words used and in which context as
>> > that way one will not use the imaginative meanings or wrong meanings
>> > that stem from person's mind.
>> For the record; I have no traumas, and if I did I would certainly not
>> ask for the advice on the Internet but I can't be not to comment your
>> statements:
>>
>> Do you mean, when people have traumas, they should get a dictionary to
>> read, to make them feel better? Because that is what you are saying! :D
>> Is that seriously what you are claiming, or you are just trying to be
>> ironic/sarcastic?
>>
>> If that is so, then I hope you are not working as a psychiatrist. That
>> sounds a little bit odd if you believe that people have traumas because
>> they got wrong meaning of a word. I would rather claim the
>> opposite. Also saying people use imaginative meanings is quite a wild
>> claim; that is somethign you would have to assert on per case basis.
>
> The last time I had trauma, it was from ringing my head after hitting a glass door.
> I absolutely did not see the door.  Why do people have to clean so good!
If you just had a dictionary .... :-)

Btw, I once did the same. Was too lazy to turn on lights but I could
still barely see in the corridor; forgott there was a glass door in that
corridor which I didn't see in the dark, and found myself sitting on the
floor after like 5 steps into the corridor. I had a scar on my nose for
like few weeks; everythign was blue in front of my eyes when I banged
into it :-)

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 8:02 AM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Jean Louis" <bugs@gnu.support>, "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> >> Sent: Friday, November 27, 2020 at 7:27 AM
> >> From: "Arthur Miller" <arthur.miller@live.com>
> >> To: "Jean Louis" <bugs@gnu.support>
> >> Cc: "Christopher Dimech" <dimech@gmx.com>, "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> >> Subject: Re: Auto Fill Comments
> >>
> >> Jean Louis <bugs@gnu.support> writes:
> >>
> >> > * Christopher Dimech <dimech@gmx.com> [2020-11-27 05:22]:
> >> >> > Sent: Friday, November 27, 2020 at 2:57 AM
> >> >> > From: "arthur miller" <arthur.miller@live.com>
> >> >> > To: "Christopher Dimech" <dimech@gmx.com>, "Drew Adams" <drew.adams@oracle.com>
> >> >> > Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> >> >> > Subject: RE: RE: Auto Fill Comments
> >> >> >
> >> >> > Yes, Emacs terminology is old.
> >> >
> >> > It may be old but not obsolete. You may be younger than Emacs and you
> >> > encounter things that were already there before you, but need not be
> >> > obsolete.
> >> >
> >> >> I dislike killing stuff, reminds me > of war, I never heard word
> >> >> yank before I start using and font > locking sounds like I am in a
> >> >> prison. But if you can go past few > names, Emacs is quite useful
> >> >> piece of software. Probably the most > advanced terminal emulator I
> >> >> have ever used, and it even has a > text editor built in.
> >> >
> >> > Words cannot and should not be chosen in the manner not to affect each
> >> > person. There is subset of words we name vulgar or obscene and they
> >> > are such because people agree to be so and that such should not be
> >> > used. Yet there is literature where such words are appropriate on the
> >> > right place.
> >> >
> >> > One reader can despise word A, other word B, other word C, other word
> >> > D, and then in the end, if one should follow that principle then
> >> > better not write at all! There is no logic in trying to accommodate
> >> > every person's traumatic experiences.
> >> >
> >> > What does make sense to help in understanding is using dictionaries
> >> > and finding definitions.
> >> >
> >> > Here I just pulled the definition of the noun "kill" and verb "kill"
> >> > from the Wordnet dictionary:
> >> >
> >> > The noun does not apply in the Emacs context as it is not verb. But
> >> > even the noun here shows that "killing" may be used in the sense of
> >> > very large profit. See:
> >> > https://idioms.thefreedictionary.com/make+a+killing
> >> >
> >> > The word in itself is harmless. Trauma that person associates with the
> >> > word is what hurts the person. To lessen that effect it is advisable
> >> > to find the true meanings of the words used and in which context as
> >> > that way one will not use the imaginative meanings or wrong meanings
> >> > that stem from person's mind.
> >> >
> >> > * Overview of noun killing
> >> >
> >> > The noun killing has 3 senses (first 2 from tagged texts)
> >> > 1. (5) killing, violent death -- (an event that causes someone to die)
> >> > 2. (5) killing, kill, putting to death -- (the act of terminating a life)
> >> > 3. killing, cleanup -- (a very large profit)
> >> >
> >> > Not even English speaking people will know that the verb "kill" has
> >> > this many senses. One can see that definition number 12 applies here:
> >> >
> >> > 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or
> >> > erase; "kill these lines in the President's speech")
> >> >
> >> > Thus the verb "to kill" is part of English language. If person is not
> >> > English speaker or does not find proper definitions of course that
> >> > most used definition will be used. If you find yourself having
> >> > troubles or you find something not logical, please open up dictionary
> >> > and look up definitions.
> >> >
> >> > One can see in the below examples that there are other valid uses of
> >> > the word "kill" in various senses.
> >> >
> >> > * Overview of verb kill
> >> >
> >> > The verb kill has 15 senses (first 3 from tagged texts)
> >> > 1. (103) kill -- (cause to die; put to death, usually intentionally or
> >> > knowingly; "This man killed several people when he tried to rob a bank"; "The
> >> > farmer killed a pig for the holidays")
> >> > 2. (1) kill, shoot down, defeat, vote down, vote out -- (thwart the passage of; "kill a motion"; "he shot down the student's proposal")
> >> > 3. (1) stamp out, kill -- (end or extinguish by forceful means; "Stamp out poverty!")
> >> > 4. kill -- (be fatal; "cigarettes kill"; "drunken driving kills")
> >> > 5. kill -- (be the source of great pain for; "These new shoes are killing me!")
> >> > 6. kill -- (overwhelm with hilarity, pleasure, or admiration; "The comedian was so funny, he was killing me!")
> >> > 7. kill -- (hit with so much force as to make a return impossible, in racket games; "She killed the ball")
> >> > 8. kill -- (hit with great force; "He killed the ball")
> >> > 9. kill -- (deprive of life; "AIDS has killed thousands in Africa")
> >> > 10. kill -- (cause the death of, without intention; "She was killed in the collision of three cars")
> >> > 11. toss off, pop, bolt down, belt down, pour down, down, drink down, kill --
> >> > (drink down entirely; "He downed three martinis before dinner"; "She killed a
> >> > bottle of brandy that night"; "They popped a few beer after work")
> >> > 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or erase; "kill these lines in the President's speech")
> >> > 13. kill -- (tire out completely; "The daily stress of her work is killing her")
> >> > 14. kill -- (cause to cease operating; "kill the engine")
> >> > 15. kill -- (destroy a vitally essential quality of or in; "Eating artichokes kills the taste of all other foods")
> >>
> >> > What does make sense to help in understanding is using dictionaries
> >> > and finding definitions.
> >> Indeed; my engish really sux I know! Thank your posting the meaning of
> >> world kill, being long time until I worked on my glossary.
> >>
> >> Frankly I said old; I didn't said obsolete; nor incomprehensive;
> >> on contrary. Didn't you read that from the message I tried to convey?
> >>
> >> I think you are going into waters we don't need to go to here. I was
> >> illustrating to the guy that everybody can find things to disslike, but
> >> at the end terminology is just names, just a combination of characters
> >> or sounds not to get attached to.
> >>
> >> > If you find yourself having
> >> > troubles or you find something not logical, please open up dictionary
> >> > and look up definitions.
> >>
> >> > The word in itself is harmless. Trauma that person associates with the
> >> > word is what hurts the person. To lessen that effect it is advisable
> >> > to find the true meanings of the words used and in which context as
> >> > that way one will not use the imaginative meanings or wrong meanings
> >> > that stem from person's mind.
> >> For the record; I have no traumas, and if I did I would certainly not
> >> ask for the advice on the Internet but I can't be not to comment your
> >> statements:
> >>
> >> Do you mean, when people have traumas, they should get a dictionary to
> >> read, to make them feel better? Because that is what you are saying! :D
> >> Is that seriously what you are claiming, or you are just trying to be
> >> ironic/sarcastic?
> >>
> >> If that is so, then I hope you are not working as a psychiatrist. That
> >> sounds a little bit odd if you believe that people have traumas because
> >> they got wrong meaning of a word. I would rather claim the
> >> opposite. Also saying people use imaginative meanings is quite a wild
> >> claim; that is somethign you would have to assert on per case basis.
> >
> > The last time I had trauma, it was from ringing my head after hitting a glass door.
> > I absolutely did not see the door.  Why do people have to clean so good!
> If you just had a dictionary .... :-)
>
> Btw, I once did the same. Was too lazy to turn on lights but I could
> still barely see in the corridor; forgott there was a glass door in that
> corridor which I didn't see in the dark, and found myself sitting on the
> floor after like 5 steps into the corridor. I had a scar on my nose for
> like few weeks; everythign was blue in front of my eyes when I banged
> into it :-)

Do you remember Dennis Rodman telling how he broke his dick 3 times?

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Friday, November 27, 2020 at 8:02 AM
>> From: "Arthur Miller" <arthur.miller@live.com>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: "Jean Louis" <bugs@gnu.support>, "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
>> Subject: Re: Auto Fill Comments
>>
>> Christopher Dimech <dimech@gmx.com> writes:
>>
>> >> Sent: Friday, November 27, 2020 at 7:27 AM
>> >> From: "Arthur Miller" <arthur.miller@live.com>
>> >> To: "Jean Louis" <bugs@gnu.support>
>> >> Cc: "Christopher Dimech" <dimech@gmx.com>, "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
>> >> Subject: Re: Auto Fill Comments
>> >>
>> >> Jean Louis <bugs@gnu.support> writes:
>> >>
>> >> > * Christopher Dimech <dimech@gmx.com> [2020-11-27 05:22]:
>> >> >> > Sent: Friday, November 27, 2020 at 2:57 AM
>> >> >> > From: "arthur miller" <arthur.miller@live.com>
>> >> >> > To: "Christopher Dimech" <dimech@gmx.com>, "Drew Adams" <drew.adams@oracle.com>
>> >> >> > Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
>> >> >> > Subject: RE: RE: Auto Fill Comments
>> >> >> >
>> >> >> > Yes, Emacs terminology is old.
>> >> >
>> >> > It may be old but not obsolete. You may be younger than Emacs and you
>> >> > encounter things that were already there before you, but need not be
>> >> > obsolete.
>> >> >
>> >> >> I dislike killing stuff, reminds me > of war, I never heard word
>> >> >> yank before I start using and font > locking sounds like I am in a
>> >> >> prison. But if you can go past few > names, Emacs is quite useful
>> >> >> piece of software. Probably the most > advanced terminal emulator I
>> >> >> have ever used, and it even has a > text editor built in.
>> >> >
>> >> > Words cannot and should not be chosen in the manner not to affect each
>> >> > person. There is subset of words we name vulgar or obscene and they
>> >> > are such because people agree to be so and that such should not be
>> >> > used. Yet there is literature where such words are appropriate on the
>> >> > right place.
>> >> >
>> >> > One reader can despise word A, other word B, other word C, other word
>> >> > D, and then in the end, if one should follow that principle then
>> >> > better not write at all! There is no logic in trying to accommodate
>> >> > every person's traumatic experiences.
>> >> >
>> >> > What does make sense to help in understanding is using dictionaries
>> >> > and finding definitions.
>> >> >
>> >> > Here I just pulled the definition of the noun "kill" and verb "kill"
>> >> > from the Wordnet dictionary:
>> >> >
>> >> > The noun does not apply in the Emacs context as it is not verb. But
>> >> > even the noun here shows that "killing" may be used in the sense of
>> >> > very large profit. See:
>> >> > https://idioms.thefreedictionary.com/make+a+killing
>> >> >
>> >> > The word in itself is harmless. Trauma that person associates with the
>> >> > word is what hurts the person. To lessen that effect it is advisable
>> >> > to find the true meanings of the words used and in which context as
>> >> > that way one will not use the imaginative meanings or wrong meanings
>> >> > that stem from person's mind.
>> >> >
>> >> > * Overview of noun killing
>> >> >
>> >> > The noun killing has 3 senses (first 2 from tagged texts)
>> >> > 1. (5) killing, violent death -- (an event that causes someone to die)
>> >> > 2. (5) killing, kill, putting to death -- (the act of terminating a life)
>> >> > 3. killing, cleanup -- (a very large profit)
>> >> >
>> >> > Not even English speaking people will know that the verb "kill" has
>> >> > this many senses. One can see that definition number 12 applies here:
>> >> >
>> >> > 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or
>> >> > erase; "kill these lines in the President's speech")
>> >> >
>> >> > Thus the verb "to kill" is part of English language. If person is not
>> >> > English speaker or does not find proper definitions of course that
>> >> > most used definition will be used. If you find yourself having
>> >> > troubles or you find something not logical, please open up dictionary
>> >> > and look up definitions.
>> >> >
>> >> > One can see in the below examples that there are other valid uses of
>> >> > the word "kill" in various senses.
>> >> >
>> >> > * Overview of verb kill
>> >> >
>> >> > The verb kill has 15 senses (first 3 from tagged texts)
>> >> > 1. (103) kill -- (cause to die; put to death, usually intentionally or
>> >> > knowingly; "This man killed several people when he tried to rob a bank"; "The
>> >> > farmer killed a pig for the holidays")
>> >> > 2. (1) kill, shoot down, defeat, vote down, vote out -- (thwart the passage of; "kill a motion"; "he shot down the student's proposal")
>> >> > 3. (1) stamp out, kill -- (end or extinguish by forceful means; "Stamp out poverty!")
>> >> > 4. kill -- (be fatal; "cigarettes kill"; "drunken driving kills")
>> >> > 5. kill -- (be the source of great pain for; "These new shoes are killing me!")
>> >> > 6. kill -- (overwhelm with hilarity, pleasure, or admiration; "The comedian was so funny, he was killing me!")
>> >> > 7. kill -- (hit with so much force as to make a return impossible, in racket games; "She killed the ball")
>> >> > 8. kill -- (hit with great force; "He killed the ball")
>> >> > 9. kill -- (deprive of life; "AIDS has killed thousands in Africa")
>> >> > 10. kill -- (cause the death of, without intention; "She was killed in the collision of three cars")
>> >> > 11. toss off, pop, bolt down, belt down, pour down, down, drink down, kill --
>> >> > (drink down entirely; "He downed three martinis before dinner"; "She killed a
>> >> > bottle of brandy that night"; "They popped a few beer after work")
>> >> > 12. kill, obliterate, wipe out -- (mark for deletion, rub off, or erase; "kill these lines in the President's speech")
>> >> > 13. kill -- (tire out completely; "The daily stress of her work is killing her")
>> >> > 14. kill -- (cause to cease operating; "kill the engine")
>> >> > 15. kill -- (destroy a vitally essential quality of or in; "Eating artichokes kills the taste of all other foods")
>> >>
>> >> > What does make sense to help in understanding is using dictionaries
>> >> > and finding definitions.
>> >> Indeed; my engish really sux I know! Thank your posting the meaning of
>> >> world kill, being long time until I worked on my glossary.
>> >>
>> >> Frankly I said old; I didn't said obsolete; nor incomprehensive;
>> >> on contrary. Didn't you read that from the message I tried to convey?
>> >>
>> >> I think you are going into waters we don't need to go to here. I was
>> >> illustrating to the guy that everybody can find things to disslike, but
>> >> at the end terminology is just names, just a combination of characters
>> >> or sounds not to get attached to.
>> >>
>> >> > If you find yourself having
>> >> > troubles or you find something not logical, please open up dictionary
>> >> > and look up definitions.
>> >>
>> >> > The word in itself is harmless. Trauma that person associates with the
>> >> > word is what hurts the person. To lessen that effect it is advisable
>> >> > to find the true meanings of the words used and in which context as
>> >> > that way one will not use the imaginative meanings or wrong meanings
>> >> > that stem from person's mind.
>> >> For the record; I have no traumas, and if I did I would certainly not
>> >> ask for the advice on the Internet but I can't be not to comment your
>> >> statements:
>> >>
>> >> Do you mean, when people have traumas, they should get a dictionary to
>> >> read, to make them feel better? Because that is what you are saying! :D
>> >> Is that seriously what you are claiming, or you are just trying to be
>> >> ironic/sarcastic?
>> >>
>> >> If that is so, then I hope you are not working as a psychiatrist. That
>> >> sounds a little bit odd if you believe that people have traumas because
>> >> they got wrong meaning of a word. I would rather claim the
>> >> opposite. Also saying people use imaginative meanings is quite a wild
>> >> claim; that is somethign you would have to assert on per case basis.
>> >
>> > The last time I had trauma, it was from ringing my head after hitting a glass door.
>> > I absolutely did not see the door.  Why do people have to clean so good!
>> If you just had a dictionary .... :-)
>>
>> Btw, I once did the same. Was too lazy to turn on lights but I could
>> still barely see in the corridor; forgott there was a glass door in that
>> corridor which I didn't see in the dark, and found myself sitting on the
>> floor after like 5 steps into the corridor. I had a scar on my nose for
>> like few weeks; everythign was blue in front of my eyes when I banged
>> into it :-)
>
> Do you remember Dennis Rodman telling how he broke his dick 3 times?
I am affraid not. But let's stop here since this is quite unrelated to emacs.

Re: Auto Fill Comments

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-11-27 09:28]:

> > What does make sense to help in understanding is using dictionaries
> > and finding definitions.
> Indeed; my engish really sux I know! Thank your posting the meaning of
> world kill, being long time until I worked on my glossary.

> Frankly I said old; I didn't said obsolete; nor incomprehensive;
> on contrary. Didn't you read that from the message I tried to
> convey?

I see, thank you. 

> I think you are going into waters we don't need to go to here. I was
> illustrating to the guy that everybody can find things to disslike, but
> at the end terminology is just names, just a combination of characters
> or sounds not to get attached to.

That is it.

But in general I was thinking I am replying on other person's
statement, maybe I got lost. My point is exactly is you stated above
that one may dislike things and that it is better to look what the
word really is, just characters and sounds and meanings.

There is no logical need to connect those meanings to get reminded of
any problems. But that is in fact so, people do, as we are not
perfect.

Specific words and writings are triggers for unexpected reactions
which historical source does not stem from the present time.

> > The word in itself is harmless. Trauma that person associates with the
> > word is what hurts the person. To lessen that effect it is advisable
> > to find the true meanings of the words used and in which context as
> > that way one will not use the imaginative meanings or wrong meanings
> > that stem from person's mind.
> For the record; I have no traumas, and if I did I would certainly not
> ask for the advice on the Internet but I can't be not to comment your
> statements:

I do not refer to you personally. I referred to "reminding of
killings" when reading the word "kill" in Emacs Manual.

> Do you mean, when people have traumas, they should get a dictionary to
> read, to make them feel better? Because that is what you are saying! :D
> Is that seriously what you are claiming, or you are just trying to be
> ironic/sarcastic?

I was specific and not sarcastic neither ironic. Neither I said what
you say in this paragraph neither meant it so. Sorry for
misunderstanding.

If any person does not know the meaning of a word "kill" in the sense
of wiping out some text or lines, that person may connect the word to
the only meaning that person knows which could be related to causing
to die. As the intention of the manual is not to cause people think
what it was meant, reader could be aware that something is not logical
there and should be able to find the true meaning of the word "kill"
in the context where it relates to deleting parts of text. This way
any raised emotions or memories or associations are calmed down.

> That sounds a little bit odd if you believe that people have traumas
> because they got wrong meaning of a word.

I did not say so neither expressed it so, maybe I have not expressed
myself very clear. My point was just the same as you said that words
are words with its characters, sound and meanings.

> I would rather claim the opposite. Also saying people use
> imaginative meanings is quite a wild claim; that is somethign you
> would have to assert on per case basis.

You may claim the opposite but you did not see that I do not claim the
opposite neither is important.

When I mentioned "imaginative meaning" I meant "the one meaning out of
context that person has". When reading the word "kill" without knowing
what it means in the context of deleting text, the only thing person
can think of is "causing somebody to die".

By simple reading one can over time learn what words mean without
consulting dictionary, but by consulting the proper definition one
learns it faster.

Example sentence:

Haskell programmer lost significant weight as he never came trough his
larval stage.

Without knowing what "Haskell" is or "larval stage" person reading
that sentence can get other meanings, what I meant with "imaginative"
meanings, those known to the person. What if instead of "Haskell" we
used "Brainfuck"?

Brainfuck programmer lost significant weight as he never came trough his
larval stage.

Then person could think that programmer is brainfucked instead that
programmer works in brainfuck language. Right? In absence of a true
meaning readers will put their own meanings or imaginative meanings or
replacements.

One has to know definition of each word to understand it and to
prevent replacement meanings that occur by itself when one does not
know the true one.

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

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

Larval stage:
http://catb.org/jargon/html/L/larval-stage.html

My important point is that Emacs Manual uses word "kill" or other
words that in other contexts mean something else. Readers are advised
to find the definition in dictionaries that fits into the context. If
such cannot be found as it is computer terminology then maybe asking
here or searching Internet can help.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 8:00 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Arthur Miller" <arthur.miller@live.com>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> Subject: Re: Auto Fill Comments
>
> * Arthur Miller <arthur.miller@live.com> [2020-11-27 09:28]:
>
> > > What does make sense to help in understanding is using dictionaries
> > > and finding definitions.
> > Indeed; my engish really sux I know! Thank your posting the meaning of
> > world kill, being long time until I worked on my glossary.
>
> > Frankly I said old; I didn't said obsolete; nor incomprehensive;
> > on contrary. Didn't you read that from the message I tried to
> > convey?
>
> I see, thank you.
>
> > I think you are going into waters we don't need to go to here. I was
> > illustrating to the guy that everybody can find things to disslike, but
> > at the end terminology is just names, just a combination of characters
> > or sounds not to get attached to.
>
> That is it.
>
> But in general I was thinking I am replying on other person's
> statement, maybe I got lost. My point is exactly is you stated above
> that one may dislike things and that it is better to look what the
> word really is, just characters and sounds and meanings.
>
> There is no logical need to connect those meanings to get reminded of
> any problems. But that is in fact so, people do, as we are not
> perfect.
>
> Specific words and writings are triggers for unexpected reactions
> which historical source does not stem from the present time.
>
> > > The word in itself is harmless. Trauma that person associates with the
> > > word is what hurts the person. To lessen that effect it is advisable
> > > to find the true meanings of the words used and in which context as
> > > that way one will not use the imaginative meanings or wrong meanings
> > > that stem from person's mind.
> > For the record; I have no traumas, and if I did I would certainly not
> > ask for the advice on the Internet but I can't be not to comment your
> > statements:
>
> I do not refer to you personally. I referred to "reminding of
> killings" when reading the word "kill" in Emacs Manual.

Perhaps they lived in Louisiana!

> > Do you mean, when people have traumas, they should get a dictionary to
> > read, to make them feel better? Because that is what you are saying! :D
> > Is that seriously what you are claiming, or you are just trying to be
> > ironic/sarcastic?
>
> I was specific and not sarcastic neither ironic. Neither I said what
> you say in this paragraph neither meant it so. Sorry for
> misunderstanding.
>
> If any person does not know the meaning of a word "kill" in the sense
> of wiping out some text or lines, that person may connect the word to
> the only meaning that person knows which could be related to causing
> to die. As the intention of the manual is not to cause people think
> what it was meant, reader could be aware that something is not logical
> there and should be able to find the true meaning of the word "kill"
> in the context where it relates to deleting parts of text. This way
> any raised emotions or memories or associations are calmed down.
>
> > That sounds a little bit odd if you believe that people have traumas
> > because they got wrong meaning of a word.
>
> I did not say so neither expressed it so, maybe I have not expressed
> myself very clear. My point was just the same as you said that words
> are words with its characters, sound and meanings.
>
> > I would rather claim the opposite. Also saying people use
> > imaginative meanings is quite a wild claim; that is somethign you
> > would have to assert on per case basis.
>
> You may claim the opposite but you did not see that I do not claim the
> opposite neither is important.
>
> When I mentioned "imaginative meaning" I meant "the one meaning out of
> context that person has". When reading the word "kill" without knowing
> what it means in the context of deleting text, the only thing person
> can think of is "causing somebody to die".
>
> By simple reading one can over time learn what words mean without
> consulting dictionary, but by consulting the proper definition one
> learns it faster.
>
> Example sentence:
>
> Haskell programmer lost significant weight as he never came trough his
> larval stage.
>
> Without knowing what "Haskell" is or "larval stage" person reading
> that sentence can get other meanings, what I meant with "imaginative"
> meanings, those known to the person. What if instead of "Haskell" we
> used "Brainfuck"?
>
> Brainfuck programmer lost significant weight as he never came trough his
> larval stage.
>
> Then person could think that programmer is brainfucked instead that
> programmer works in brainfuck language. Right? In absence of a true
> meaning readers will put their own meanings or imaginative meanings or
> replacements.
>
> One has to know definition of each word to understand it and to
> prevent replacement meanings that occur by itself when one does not
> know the true one.
>
> https://en.wikipedia.org/wiki/Haskell
>
> https://en.wikipedia.org/wiki/Brainfuck
>
> Larval stage:
> http://catb.org/jargon/html/L/larval-stage.html
>
> My important point is that Emacs Manual uses word "kill" or other
> words that in other contexts mean something else. Readers are advised
> to find the definition in dictionaries that fits into the context. If
> such cannot be found as it is computer terminology then maybe asking
> here or searching Internet can help.
>
>

Re: Auto Fill Comments

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-11-27 09:28]:
>
>> > What does make sense to help in understanding is using dictionaries
>> > and finding definitions.
>> Indeed; my engish really sux I know! Thank your posting the meaning of
>> world kill, being long time until I worked on my glossary.
>
>> Frankly I said old; I didn't said obsolete; nor incomprehensive;
>> on contrary. Didn't you read that from the message I tried to
>> convey?
>
> I see, thank you. 
>
>> I think you are going into waters we don't need to go to here. I was
>> illustrating to the guy that everybody can find things to disslike, but
>> at the end terminology is just names, just a combination of characters
>> or sounds not to get attached to.
>
> That is it.
>
> But in general I was thinking I am replying on other person's
> statement, maybe I got lost. My point is exactly is you stated above
> that one may dislike things and that it is better to look what the
> word really is, just characters and sounds and meanings.
>
> There is no logical need to connect those meanings to get reminded of
> any problems. But that is in fact so, people do, as we are not
> perfect.
>
> Specific words and writings are triggers for unexpected reactions
> which historical source does not stem from the present time.
>
>> > The word in itself is harmless. Trauma that person associates with the
>> > word is what hurts the person. To lessen that effect it is advisable
>> > to find the true meanings of the words used and in which context as
>> > that way one will not use the imaginative meanings or wrong meanings
>> > that stem from person's mind.
>> For the record; I have no traumas, and if I did I would certainly not
>> ask for the advice on the Internet but I can't be not to comment your
>> statements:
>
> I do not refer to you personally. I referred to "reminding of
> killings" when reading the word "kill" in Emacs Manual.
>
>> Do you mean, when people have traumas, they should get a dictionary to
>> read, to make them feel better? Because that is what you are saying! :D
>> Is that seriously what you are claiming, or you are just trying to be
>> ironic/sarcastic?
>
> I was specific and not sarcastic neither ironic. Neither I said what
> you say in this paragraph neither meant it so. Sorry for
> misunderstanding.
>
> If any person does not know the meaning of a word "kill" in the sense
> of wiping out some text or lines, that person may connect the word to
> the only meaning that person knows which could be related to causing
> to die. As the intention of the manual is not to cause people think
> what it was meant, reader could be aware that something is not logical
> there and should be able to find the true meaning of the word "kill"
> in the context where it relates to deleting parts of text. This way
> any raised emotions or memories or associations are calmed down.
>
>> That sounds a little bit odd if you believe that people have traumas
>> because they got wrong meaning of a word.
>
> I did not say so neither expressed it so, maybe I have not expressed
> myself very clear. My point was just the same as you said that words
> are words with its characters, sound and meanings.
>
>> I would rather claim the opposite. Also saying people use
>> imaginative meanings is quite a wild claim; that is somethign you
>> would have to assert on per case basis.
>
> You may claim the opposite but you did not see that I do not claim the
> opposite neither is important.
>
> When I mentioned "imaginative meaning" I meant "the one meaning out of
> context that person has". When reading the word "kill" without knowing
> what it means in the context of deleting text, the only thing person
> can think of is "causing somebody to die".
>
> By simple reading one can over time learn what words mean without
> consulting dictionary, but by consulting the proper definition one
> learns it faster.
>
> Example sentence:
>
> Haskell programmer lost significant weight as he never came trough his
> larval stage.
>
> Without knowing what "Haskell" is or "larval stage" person reading
> that sentence can get other meanings, what I meant with "imaginative"
> meanings, those known to the person. What if instead of "Haskell" we
> used "Brainfuck"?
>
> Brainfuck programmer lost significant weight as he never came trough his
> larval stage.
>
> Then person could think that programmer is brainfucked instead that
> programmer works in brainfuck language. Right? In absence of a true
> meaning readers will put their own meanings or imaginative meanings or
> replacements.
>
> One has to know definition of each word to understand it and to
> prevent replacement meanings that occur by itself when one does not
> know the true one.
>
> https://en.wikipedia.org/wiki/Haskell
>
> https://en.wikipedia.org/wiki/Brainfuck
>
> Larval stage:
> http://catb.org/jargon/html/L/larval-stage.html
>
> My important point is that Emacs Manual uses word "kill" or other
> words that in other contexts mean something else. Readers are advised
> to find the definition in dictionaries that fits into the context. If
> such cannot be found as it is computer terminology then maybe asking
> here or searching Internet can help.
I understood what you mean; but I tried to tell you what you actually
said, or at least how I percieve you. Of course I understand that you
don't mean it literally; but that is how it sounds; it least I
percieve it so, and I can be wrong and missunderstand you too.

I think you are onto something though, but I am not sure you are
expressing it precisely, and I am not sure I can express it well myself.

> If any person does not know the meaning of a word "kill" in the sense
> of wiping out some text or lines, that person may connect the word to
> the only meaning that person knows which could be related to causing
> to die. As the intention of the manual is not to cause people think
> what it was meant, reader could be aware that something is not logical
> there and should be able to find the true meaning of the word "kill"
> in the context where it relates to deleting parts of text. This way
> any raised emotions or memories or associations are calmed down.

That paragraph is definitely the key (I think). I can't agree completely
with you; partially I do. For the first, I think that no manual or
terminology should used words that does not stem from semantic meaning
of the language. Killing text or buffers in emacs is not very much
detached from the meaning of word kill in general. Thus it probably is
not very hard for anyone to understand what it means in the text editing
context either, right?

If somebody gets reminded of something else when they see a word, it is
not because they don't know what the word means, or what it means in
that particular context (usually). Especially not such basic word as
kill for example. Human beings can get reminded of somethign because of
certain smell, sound, colour, shape, feel, or simply a memory can come
up. Does not have necessary to be because of person knowing or not
knowing "true" meaning in the context of the language or in the context
of praticular situation (such as text editing).

> Then person could think that programmer is brainfucked instead that
> programmer works in brainfuck language. Right? In absence of a true
> meaning readers will put their own meanings or imaginative meanings or
> replacements.
Then we have silly situations we all find us in sometimes, where we are
not aware of context words are used in. If somebody who is not a
programmer hear people talking about brainfuck they certainly may think
of something else than a silly programming language. But that is just a
lack of information at particular moment. While yes, that can happen to
people; I doubt that any normally gifted person would missunderstand
what "kill" in Emacs manuals aims at. I don't think dictionary lookup is
needed in that particular case. That also attaches to this one:

> One has to know definition of each word to understand it and to
> prevent replacement meanings that occur by itself when one does not
> know the true one.

I am not sure what do you really mean with replacement meanings that
occur by themselves. Do you have some research on that? I don't think
that any normally gifted, average person, would put some imaginative
meaning into words in some new context, but I am not sure I know what I
am talking here :-). I am not an expert on the language and psychology.

I have been reading some philosophy, physics, math and programming in my
life, seldom in my first language. I have been many times in a situation
where I didn't know what a word mean, or how do they use a particular word
in a context and so on. Somehow I always knew when I didn't understand
the word or when I didn't understand how it is used, and I always
looked it up. I am not a linguist, nor have I ever studied the
language, but I am sure most people understand when they need to look up
a word. At least, that is what I percieve when I look around me, from
the life. Sure, sometimes we do get things wrong too, but not such
things that I wouldn't know what word "kill" in Emacs mean. Having
correct meaning still does not prevent from having association when I
think about it sometimes. 

> My point is exactly is you stated above
> that one may dislike things and that it is better to look what the
> word really is, just characters and sounds and meanings.

Yes, of course, but we should still be allowed to disslike things, or to
like things and to state our disslikes. It belongs to freedom. The other
thing is what practically matter. Terminology in Emacs has been brought
up so many times, and I still disslike the terminology but I can also
realize that there are more interesting things to work on, then renaming
things. Sure, I still think we would do better by cutting and pasting
then killing and yanking, but who cares really? You bind them to a key
anyway, and just think in terms of key. I mean, few shortcuts and names,
people should probably reflect about how much it really means, and that
is not much; it's just names.

>> > The word in itself is harmless. Trauma that person associates with the
>> > word is what hurts the person. To lessen that effect it is advisable
>> > to find the true meanings of the words used and in which context as
>> > that way one will not use the imaginative meanings or wrong meanings
>> > that stem from person's mind.
>> For the record; I have no traumas, and if I did I would certainly not
>> ask for the advice on the Internet but I can't be not to comment your
>> statements:

>> Do you mean, when people have traumas, they should get a dictionary to
>> read, to make them feel better? Because that is what you are saying! :D
>> Is that seriously what you are claiming, or you are just trying to be
>> ironic/sarcastic?
>
> I was specific and not sarcastic neither ironic. Neither I said what
> you say in this paragraph neither meant it so. Sorry for
> misunderstanding.
I am sorry if I missunderstand you, but this is how it comes to me:

Someone has been in a car, driving into a curve, loosing the controll
and tipping on the roof with the car. Afterwards, that person says: I
don't like to travel by car, I prefer to travel by train.

If you told them to lookup true meaning of the word car, how do you
think they would percieve that? Would that help them? I don't know;
maybe some other book would, but probably not a dictionary.

That is how I am thinking of it; and it makes me laugh, but I don't mean
in a bad way. I do understand that you mean that people should not hang
themselves on the traumatic memories, but focus on the context in which
the word is used. I agree with you, I just don't agree on the dictionary
part of it :-).

I am sorry; too lengthy; always nice to chat, but wasn't so much of the
programming I meant to do today. I wanted to font lock my auto readme
mode, I actually red the manual and I think I know how to do it know;
will see.

I wish you great day, or evening or whatever is in your part of the
world;

Cheers
/a

Re: Auto Fill Comments

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-11-27 11:26]:
> > If any person does not know the meaning of a word "kill" in the sense
> > of wiping out some text or lines, that person may connect the word to
> > the only meaning that person knows which could be related to causing
> > to die. As the intention of the manual is not to cause people think
> > what it was meant, reader could be aware that something is not logical
> > there and should be able to find the true meaning of the word "kill"
> > in the context where it relates to deleting parts of text. This way
> > any raised emotions or memories or associations are calmed down.
> 
> That paragraph is definitely the key (I think). I can't agree completely
> with you; partially I do. For the first, I think that no manual or
> terminology should used words that does not stem from semantic meaning
> of the language. Killing text or buffers in emacs is not very much
> detached from the meaning of word kill in general. Thus it probably is
> not very hard for anyone to understand what it means in the text editing
> context either, right?

It can be that it is not dettached and you as English speaker you
would know it. I cannot know as I am not native English speaker. I can
tell that in Serbo-Croatian language there is use of "kill" and
"killing" as good attributes. For example when food is good while
people are eating it could be said that it kills and because it is in
proper context people understand it. There is total separation of
context and so the meanings. It could be that in English is not so.

In those languages one can say that movie is good by saying that movie
kills. For a good band of musicians it is possible to say "they are
killing".

The reference to etymology of "kill":
https://en.wiktionary.org/wiki/kill#Etymology_1

references also words such as: strike or cut

We have "strike" for fonts and "cut" for cutting text though we do not
cut in its other meaning. To kill a line thus, deriving from that
etymology sounds quite alright and understandable. But I am just
outside observer and did not live with English speaking people all
around me. To use that term one would additionally need to be either
secretary or editor, translator, or proofreader. 

> If somebody gets reminded of something else when they see a word, it is
> not because they don't know what the word means, or what it means in
> that particular context (usually). Especially not such basic word as
> kill for example. Human beings can get reminded of somethign because of
> certain smell, sound, colour, shape, feel, or simply a memory can come
> up. Does not have necessary to be because of person knowing or not
> knowing "true" meaning in the context of the language or in the context
> of praticular situation (such as text editing).

That is right.

> > One has to know definition of each word to understand it and to
> > prevent replacement meanings that occur by itself when one does not
> > know the true one.
> 
> I am not sure what do you really mean with replacement meanings that
> occur by themselves. Do you have some research on that?

I mean the "meaning" that person may designate in absence of the real
meaning. It should be obvious and of course it is not a rule, just a
common phenomena. If word is associating to anything person will fetch
that meaning and use it, and there we have misunderstaninds.

Example is the dialogue for local variables that tells user that
variables are not safe. But user may not be programmer, could be
translator and even if programmer user has got rather incentive to
press ! rather to accept variables forever and not to be asked again.

You may see here how user asks "why would not be safe":
https://stackoverflow.com/questions/15865495/opening-a-file-in-emacs-values-that-are-not-safe
(answer I do not find adequate)

That is one of aware users that will ask. Other users like translators
will say "but I feel safe, what can this do to me?" and will say
YES. By accident I have seen similar scene in animated movie Ralph
breaks the internet where animated character says to feel safe yet it
was related to computers.

When person does not have information of "safety of data" then such
person will find replacement definition, first will pull the one which
is known and will try to understand it from what is known like "free
from danger" and person may relate it to oneself. Not to data.

> I don't think that any normally gifted average person, would put
> some imaginative meaning into words in some new context, but I am
> not sure I know what I am talking here :-). I am not an expert on
> the language and psychology.

Well. When person through repetition becomes aware that some words
cannot be understood such person will ask, clarify, verify, try to
find in glossaries and references. That is ideal scene. In my
experience I did not see that in average persons. People put their own
to them known meanings into those spoken terms and words which they do
not know.

One rule that we as startup providers have in East Africa is that we
should never accept YES, I know, I fully understand. We require person
to repeat by person's own words what was said and instructed. That is
where all the fun begins as definitely majority will be telling us
back stories we never meant to be spoken. People feel to have it
understood, but they did not, they got some idea, but that was
definitely intended idea. They used those meanings they had
available. What one does not have available in mind will be replaced
with what we have available.

Optical illusions works the same way, example is this triangle:
https://www.optics4kids.org/osa.o4k/media/optics4kids/kanizsatriangle.gif?ext=.gif

As human mind may say to see maybe 2 triangles, one white above the
black one. But in reality there is none triangle there. Mind replaces
what is missing by pieces of information which are already known.

> I have been reading some philosophy, physics, math and programming
> in my life, seldom in my first language. I have been many times in a
> situation where I didn't know what a word mean, or how do they use a
> particular word in a context and so on. Somehow I always knew when I
> didn't understand the word or when I didn't understand how it is
> used, and I always looked it up.

I admire that and that is great. But schools in the world do not use
major tool, which is dictionary. So children do not get a habit to
look up meanings and so they are left alone to find out about it.

> I am not a linguist, nor have I ever studied the language, but I am
> sure most people understand when they need to look up a word.

Try to ask people or observe. Your way of doing it is remarkable. I
would like to have around me more people with that awareness. But I
sadly don't.

> At least, that is what I percieve when I look around me, from the
> life. Sure, sometimes we do get things wrong too, but not such
> things that I wouldn't know what word "kill" in Emacs mean. Having
> correct meaning still does not prevent from having association when
> I think about it sometimes.

I remember reading it back in 1999 and back then so many new words I
was clarifying related to GNU/Linux. It took me about 1-2 years to get
them and understand them and there is still so many pieces
missing. When I first time encountered kill and yank, I have looked it
up back then and since then have no problems with it. Those are
personal experiences and if not one word there will be some other as
possible misunderstanding.

> > My point is exactly is you stated above that one may dislike
> > things and that it is better to look what the word really is, just
> > characters and sounds and meanings.
> 
> Yes, of course, but we should still be allowed to disslike things, or to
> like things and to state our disslikes. It belongs to freedom.

I am fine with it to dislike things. It is just that I prefer society
and community eager to learn, discover and clarify things. This
mailing list is good example of such community. Either that, or
community of people who give up, blow away, run away, yell or get
upset when they dislike something and do not wish to clarify
anything. 

> The other thing is what practically matter. Terminology in Emacs has
> been brought up so many times, and I still disslike the terminology
> but I can also realize that there are more interesting things to
> work on, then renaming things. Sure, I still think we would do
> better by cutting and pasting then killing and yanking, but who
> cares really?

"Cut reminds me of injuries and blood, please remove" -- there is no
point in accommodating various views. What makes sense is to use
appropriate English and computing terminologi. And "kill" as in
relation to deleting lines as it says in dictionary, is not related to
computing. It could be equivalent to strike as how words can be
striken on the paper.

paste - is it tasty mixture to be spread on bread or crackers?

Or is it maybe paste as in the meaning of hitting with fists, like "He
pasted his opponent"?

None of those words have single definition, they all have multiple
definitions that apply in different contexts. That is why I am rather
against changing what is already well well known or established
terminology. But times changes and words change too.

> Someone has been in a car, driving into a curve, loosing the controll
> and tipping on the roof with the car. Afterwards, that person says: I
> don't like to travel by car, I prefer to travel by train.
> 
> If you told them to lookup true meaning of the word car, how do you
> think they would percieve that? Would that help them? I don't know;
> maybe some other book would, but probably not a dictionary.

I am not sure there as person driving a car would know what is car. If
car is Emacs then please think that most car drivers do not know how
carburetor function or how engine works. Tutorial is for driving Emacs
safely on the road. Emacs Manual tells how to tune the engine. Then
they may complain because fingers are dirty of oil.

Jean

Re: Auto Fill Comments

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> Date: Fri, 27 Nov 2020 01:57:37 +0000
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> Yes, Emacs terminology is old.

Which is why we have an elaborate Glossary chapter in the manual.

RE: RE: Auto Fill Comments

[Drew Adams]

> The manuals should be rewritten because they are
> incomprehensible.  Perhaps it was good in the eighties.

Maybe.  Or maybe programmers in the eighties
read more? or better?

Would you like to contribute to rewriting or
otherwise improving the manuals?  The job's
open.

> It continues forever.

Yep, Emacs gives you a lifetime of learning,
if you let it.

> Consider "face customisation" for instance,
> which just means font.  

Bzzzzzzt!  Nope.  But thanks for playing.

> Nobody fuckin reads a manual with 17 nodes.

I do.  I'm not nobody.

Those who developed Emacs, and those who
continue to develop it, feel that Emacs doc
is vitally important to what Emacs is and
what it aims to be.

Personally, I couldn't be more thankful for
that perspective.  That's my Thanksgiving
message...

> You don't know which one to use, which
> commands are most useful, and so on.

You don't know if you don't read - true.
You don't know if you don't try - true.

> The problem gets compounded because every
> esoteric command is there.

No.  Most commands (and most functions, keys,
faces,...) are intentionally NOT documented
in the manuals.  Likewise, for most "esoteric"
commands (functions,...).

Your verdict reminds me of Emperor Joseph
telling Mozart there were too many notes...

Too many books in the library.  Internet's
too big.  What's a body to do?

> You are just insisting on something bad
> and inefficient.

You are just insisting that people help
you find info that's easy for you to find,
yourself.

I don't insist that you read the manuals.
Not at all.  Your loss, if you don't.  Or
maybe you'll be able to continue getting
spoon-fed here.  Good luck with that.

I'm actually glad people here help you.
I was trying to let you know that people
might be all the more likely to help if you
show some research effort.

Do I think Emacs users should ask questions?
Absolutely.  Do I sometimes help Emacs users
by answering questions?  Sure do - every day.

But the single best way I can help in that
regard is to help learn how to "Ask Emacs".

https://quoteinvestigator.com/2015/08/28/fish/
___

You wanna know how it was in the _real_
good-ole days?

http://www2.phy.ilstu.edu/pte/209content/agassiz.html

Re: RE: RE: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 3:15 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: RE: RE: Auto Fill Comments
>
> > The manuals should be rewritten because they are
> > incomprehensible.  Perhaps it was good in the eighties.
>
> Maybe.  Or maybe programmers in the eighties
> read more? or better?

Maybe, but today there is a problem of too much material.

> Would you like to contribute to rewriting or
> otherwise improving the manuals?  The job's
> open.

Sure, I'm working on it.

> > It continues forever.
>
> Yep, Emacs gives you a lifetime of learning,
> if you let it.
>
> > Consider "face customisation" for instance,
> > which just means font.
>
> Bzzzzzzt!  Nope.  But thanks for playing.
>
> > Nobody fuckin reads a manual with 17 nodes.
>
> I do.  I'm not nobody.
>
> Those who developed Emacs, and those who
> continue to develop it, feel that Emacs doc
> is vitally important to what Emacs is and
> what it aims to be.

Yes, for those who have spent quite some time
on emacs it could be good enough.

> Personally, I couldn't be more thankful for
> that perspective.  That's my Thanksgiving
> message...
>
> > You don't know which one to use, which
> > commands are most useful, and so on.
>
> You don't know if you don't read - true.
> You don't know if you don't try - true.
>
> > The problem gets compounded because every
> > esoteric command is there.
>
> No.  Most commands (and most functions, keys,
> faces,...) are intentionally NOT documented
> in the manuals.  Likewise, for most "esoteric"
> commands (functions,...).
>
> Your verdict reminds me of Emperor Joseph
> telling Mozart there were too many notes...

Do you think most are Mozart?  We ain't!

> Too many books in the library.  Internet's
> too big.  What's a body to do?
>
> > You are just insisting on something bad
> > and inefficient.
>
> You are just insisting that people help
> you find info that's easy for you to find,
> yourself.
>
> I don't insist that you read the manuals.
> Not at all.  Your loss, if you don't.  Or
> maybe you'll be able to continue getting
> spoon-fed here.  Good luck with that.

Wait a while ;)

> I'm actually glad people here help you.
> I was trying to let you know that people
> might be all the more likely to help if you
> show some research effort.

Will ask more complicated as I work more on it.
I got into elisp to help me in what I was doing
without too much time reading for the joy of it.
But yes, I should do it.

> Do I think Emacs users should ask questions?
> Absolutely.  Do I sometimes help Emacs users
> by answering questions?  Sure do - every day.
>
> But the single best way I can help in that
> regard is to help learn how to "Ask Emacs".

> https://quoteinvestigator.com/2015/08/28/fish/
> ___
>
> You wanna know how it was in the _real_
> good-ole days?
>
> http://www2.phy.ilstu.edu/pte/209content/agassiz.html

One got to endure with what one's got I suppose.

RE: RE: RE: Auto Fill Comments

[Drew Adams]

> > Would you like to contribute to rewriting or
> > otherwise improving the manuals?  The job's
> > open.
> 
> Sure, I'm working on it.

Excellent!  That's the spirit.

One way to contribute enhancement suggestions,
however large or small, is to file an enhancement
request with the suggestion.  You can use
`M-x report-emacs-bug' for that (it's not just
for bug reports).

Re: RE: RE: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-11-27 05:43]:
> Will ask more complicated as I work more on it.
> I got into elisp to help me in what I was doing
> without too much time reading for the joy of it.
> But yes, I should do it.

Please tell me, just to understand how you started:

- did you start reading Emacs Lisp manual as first?

- or did you maybe read Emacs Lisp Intro first?

Jean

Re: RE: RE: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 6:47 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: RE: RE: Auto Fill Comments
>
> * Christopher Dimech <dimech@gmx.com> [2020-11-27 05:43]:
> > Will ask more complicated as I work more on it.
> > I got into elisp to help me in what I was doing
> > without too much time reading for the joy of it.
> > But yes, I should do it.
>
> Please tell me, just to understand how you started:
>
> - did you start reading Emacs Lisp manual as first?
>
> - or did you maybe read Emacs Lisp Intro first?

Started with Emacs Lisp Manual , then Emacs Lisp Intro.
But when I got the buffer-local for the sake of auto-fill,
I was finished, Kaput.

Anyway, we don't want to rant forever.

> Jean
>
>

Re: RE: RE: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-11-27 09:08]:
> Started with Emacs Lisp Manual , then Emacs Lisp Intro.
> But when I got the buffer-local for the sake of auto-fill,
> I was finished, Kaput.
> 
> Anyway, we don't want to rant forever.

I have never used buffer local variables. Recently, developers of
`emacs-libpq' dynamic module for direct access to PostgreSQL mentioned
using buffer local variables to keep note of a variable holding the
database handle.

That would probably mean it would be opening multiple TCP connections
to the database per each buffer using such handles.

As I am working with the database being displayed in Emacs I will soon
need to start creating different buffers for different displays of the
database backed reports. And I wonder if I will need to use buffer
local variables for that or I will just need to make buffers by new
names that they reuse the database handle. Probably this way.

But what about using multiple buffers where one has per buffer marked
items or filtering options. Then such should probably become buffer
local or otherwise such variables global over buffers would influence
display in various buffers.

Re: RE: RE: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 7:21 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: RE: RE: Auto Fill Comments
>
> * Christopher Dimech <dimech@gmx.com> [2020-11-27 09:08]:
> > Started with Emacs Lisp Manual , then Emacs Lisp Intro.
> > But when I got the buffer-local for the sake of auto-fill,
> > I was finished, Kaput.
> >
> > Anyway, we don't want to rant forever.
>
> I have never used buffer local variables. Recently, developers of
> `emacs-libpq' dynamic module for direct access to PostgreSQL mentioned
> using buffer local variables to keep note of a variable holding the
> database handle.
>
> That would probably mean it would be opening multiple TCP connections
> to the database per each buffer using such handles.
>
> As I am working with the database being displayed in Emacs I will soon
> need to start creating different buffers for different displays of the
> database backed reports. And I wonder if I will need to use buffer
> local variables for that or I will just need to make buffers by new
> names that they reuse the database handle. Probably this way.
>
> But what about using multiple buffers where one has per buffer marked
> items or filtering options. Then such should probably become buffer
> local or otherwise such variables global over buffers would influence
> display in various buffers.

Yes, you would need buffer local.  Welcome to the swamp.

Re: RE: RE: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-11-27 09:28]:
> > But what about using multiple buffers where one has per buffer marked
> > items or filtering options. Then such should probably become buffer
> > local or otherwise such variables global over buffers would influence
> > display in various buffers.
> 
> Yes, you would need buffer local.  Welcome to the swamp.

From there I can see history how they developed from that logical
need.

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Friday, November 27, 2020 at 7:21 AM
>> From: "Jean Louis" <bugs@gnu.support>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: help-gnu-emacs@gnu.org
>> Subject: Re: RE: RE: Auto Fill Comments
>>
>> * Christopher Dimech <dimech@gmx.com> [2020-11-27 09:08]:
>> > Started with Emacs Lisp Manual , then Emacs Lisp Intro.
>> > But when I got the buffer-local for the sake of auto-fill,
>> > I was finished, Kaput.
>> >
>> > Anyway, we don't want to rant forever.
>>
>> I have never used buffer local variables. Recently, developers of
>> `emacs-libpq' dynamic module for direct access to PostgreSQL mentioned
>> using buffer local variables to keep note of a variable holding the
>> database handle.
>>
>> That would probably mean it would be opening multiple TCP connections
>> to the database per each buffer using such handles.
>>
>> As I am working with the database being displayed in Emacs I will soon
>> need to start creating different buffers for different displays of the
>> database backed reports. And I wonder if I will need to use buffer
>> local variables for that or I will just need to make buffers by new
>> names that they reuse the database handle. Probably this way.
>>
>> But what about using multiple buffers where one has per buffer marked
>> items or filtering options. Then such should probably become buffer
>> local or otherwise such variables global over buffers would influence
>> display in various buffers.
>
> Yes, you would need buffer local.  Welcome to the swamp.
Not that is my business; but I think you can always hire a professional
programmer to clear the swamp for you .... ;-) :-)

Re: RE: Auto Fill Comments

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-11-27 05:19]:
> > The manuals should be rewritten because they are
> > incomprehensible.  Perhaps it was good in the eighties.
> 
> Maybe.  Or maybe programmers in the eighties
> read more? or better?
> 
> Would you like to contribute to rewriting or
> otherwise improving the manuals?  The job's
> open.
> 
> > It continues forever.
> 
> Yep, Emacs gives you a lifetime of learning,
> if you let it.
> 
> > Consider "face customisation" for instance,
> > which just means font.  
> 
> Bzzzzzzt!  Nope.  But thanks for playing.
> 
> > Nobody fuckin reads a manual with 17 nodes.
> 
> I do.  I'm not nobody.

The essential problem there in the manual is that there are many words
and new terminology that cannot be easily understood. That is why I
have proposed to have dictionary.el to be built in into Emacs, and
also much better integration and hyperlinking with the glossary.

Readers of books may know that sometimes one can read pages and pages
just to realize that nothing remained in the memory and this all can
come from misunderstood words. Same is for manuals or any text.

One could see that effect if one makes few examples from extreme
understandable text over medium understandable to extreme not
understandable text.

Something written in Klingon language would most probably be very
extremely not understandable for majority of people.

Sample text in Klingon

tlhIngan Hol yejHaD jInmol chu' 'oH Qo'noS QonoS'e'. tlhIngan Hol
jatlhwI'pu'vaD wIcherpu'. naDev vuDmey Daj lutmey Sagh je DalaDlaH,
'ach tlhIngan Hol DayajnIS. Hoch jar chovnatlh chu'
wImuch. yIlaD. yIqeq. tugh bIpo'choH.

Thus if manual would be written in Klingon, as extreme example of not
understandable text, English readers would have no use of it.

If manual would be written in the form of a well hyperlinked document
such would bring greater understanding to users. This requires
agreement among many people and is questionable if it becomes such
ever. Yet hyperlinks would enable user to quickly reference various
terms that helps in understanding.

Example of such well hyperlinked document is the Common Lisp
Hyperspec:
http://www.lispworks.com/documentation/HyperSpec/Body/03_dd.htm

Documentation of the Common Lisp Hyperspec if very complex but with
finely grained references hyperlinks it becomes pleasure to learn and
programmers can orient themselves easier in the apparently complex
document. That is example of complex instructions well prepared for
easier understanding.

Emacs TUTORIAL is good for beginners and without actually doing the
Tutorial one cannot easily understand the manual. By going through the
Tutorial also manual becomes easier to understand. Often I reference
to staff members to do the Emacs tutorial and so far I have not heard
complaints. But I also did not ask. What makes sense is that person
demonstrates that person can open file, work with it, save file and
send it by email. That is for me good indicator that Emacs Tutorial
was read and could be followed by person who is not programmer.

The Emacs manual compared to some other Emacs Manuals may not be
easiest to read and understand. It is comprehensible, it has glossary
and majority of references. And yet it is not proper for every group
of people.

Before reading the Emacs Lisp manual it is advisable to read
Emacs Lisp Introdution. Something similar to Emacs Lisp Intro to Emacs
could be Emacs Introduction, but I do not have reference and do not
know if that exists.

Books such as Mastering Emacs or O'Reilly book on Emacs are
proprietary, yet copies can be found online. 

Good way to start is also to analyze the reference card:
https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf

We speak of complex software here and in itself any manual will bring
easily misunderstood words and may block user's understanding. That is
why is advisable to use dictionaries, computer dictionaries, glossary
and to ask people for specific meanings which user cannot find.

If you have specific questions or you get stuck, please ask.

References to some simplified instructions on Emacs:

http://www.jesshamrick.com/2012/09/10/absolute-beginners-guide-to-emacs/

https://masteringemacs.org/article/beginners-guide-to-emacs

https://zoo.cs.yale.edu/classes/cs210/help/emacs.html

https://www.ozgurozkok.com/emacs-for-the-dummies/

RE: RE: Auto Fill Comments

[Drew Adams]

> Example of such well hyperlinked document is the Common Lisp
> Hyperspec:
> https://urldefense.com/v3/__http://www.lispworks.com/documentation/Hype
> rSpec/Body/03_dd.htm__;!!GqivPVa7Brio!M0oMWYk7ycXnM09iZWgxA9rs9YHwszzUU
> mkxyu4rqQ8q1NPYUklPucBUWHTBipB9$
> 
> Documentation of the Common Lisp Hyperspec if very complex but with
> finely grained references hyperlinks it becomes pleasure to learn and
> programmers can orient themselves easier in the apparently complex
> document. That is example of complex instructions well prepared for
> easier understanding.

FWIW -

Though I use the hyperspec sometimes I vastly
prefer CLTL2.  It gives you conceptual info
about the language and Lisp generally (in
addition to giving the API info that the
hyperspec provides).

CLTL describes the language design, and tells
you reasons why it's the way it is, as well as
some of the important consequences.  Someone
wondering about the seeming oddities of Lisp
will begin to understand them with CLTL.

In a nutshell, it shows you Lisp, what it is
and why.  No doubt that's why it has the title
it does: Common Lisp The Language.

You don't get that from the hyperspec.  The
hyperspec is essentially just API doc - it
provides little understanding.  (Yes, it's
hyperlinked, which is good.)

You can actually sit down and learn Common
Lisp (and Lisp generally) by reading CLTL.
It takes you from pretty much no knowledge to
pretty much complete info about the language.

CLTL is not a how-to book - not a tutorial.
It's a spec of the language, but in English,
not algebra.

(Another book that's in a similar spirit, but
isn't a spec of a particular language, is
Abelson & Sussman's Structure & Interpretation
of Computer Programs.)

Re: RE: Auto Fill Comments

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-11-27 08:32]:
> > Example of such well hyperlinked document is the Common Lisp
> > Hyperspec:
> > https://urldefense.com/v3/__http://www.lispworks.com/documentation/Hype
> > rSpec/Body/03_dd.htm__;!!GqivPVa7Brio!M0oMWYk7ycXnM09iZWgxA9rs9YHwszzUU
> > mkxyu4rqQ8q1NPYUklPucBUWHTBipB9$
> > 
> > Documentation of the Common Lisp Hyperspec if very complex but with
> > finely grained references hyperlinks it becomes pleasure to learn and
> > programmers can orient themselves easier in the apparently complex
> > document. That is example of complex instructions well prepared for
> > easier understanding.
> 
> FWIW -
> 
> Though I use the hyperspec sometimes I vastly
> prefer CLTL2.  It gives you conceptual info
> about the language and Lisp generally (in
> addition to giving the API info that the
> hyperspec provides).

You are so right, That one is easier for learning. Reference for
others:
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node1.html

> CLTL describes the language design, and tells
> you reasons why it's the way it is, as well as
> some of the important consequences.  Someone
> wondering about the seeming oddities of Lisp
> will begin to understand them with CLTL.

Basically it tells also of etymology of the term in a language which
is important in understanding also normal English or other language
words.

> You can actually sit down and learn Common
> Lisp (and Lisp generally) by reading CLTL.
> It takes you from pretty much no knowledge to
> pretty much complete info about the language.
> 
> CLTL is not a how-to book - not a tutorial.
> It's a spec of the language, but in English,
> not algebra.
> 
> (Another book that's in a similar spirit, but
> isn't a spec of a particular language, is
> Abelson & Sussman's Structure & Interpretation
> of Computer Programs.)

For reference, it may be downloaded by using this Emacs package:
https://github.com/webframp/sicp-info

There are gradual ways to full understanding. Emacs Lisp has its Emacs
Lisp Intro manual. That is one gradual step to understanding.

When subject appears way too hard it is advisable to look into
intermediate instructional texts.

I think that Emacs Manual is finely written and one better go through
first few chapters before readin further chapters. That way one get
introduced in gradual manner.

Without understanding general concepts of course that reader may find
it hard in advanced concepts.

Learning first things first is always advised for any kind of
subject..

Re: Auto Fill Comments

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Date: Fri, 27 Nov 2020 01:47:08 +0100
> Sensitivity: Normal
> Cc: help-gnu-emacs@gnu.org
> 
> The manuals should be rewritten because they are incomprehensible.
> Perhaps it was good in the eighties.  It continues forever.  Consider
> "face customisation" for instance, which just means font.  Nobody
> fuckin reads a manual with 17 nodes.  You don't know which one to use,
> which commands are most useful, and so on.  The problem gets compounded
> because every esoteric command is there.
> 
> You are just insisting on something bad and inefficient.

Fair warning: if that is your attitude towards our documentation,
please be aware that there will be some people here who'd refrain from
helping you.  We don't work for you, so if you refuse to help yourself
by becoming more proficient with the extensive documentation features
in Emacs, we cannot be expected to hold your hand forever.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 8:28 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Date: Fri, 27 Nov 2020 01:47:08 +0100
> > Sensitivity: Normal
> > Cc: help-gnu-emacs@gnu.org
> >
> > The manuals should be rewritten because they are incomprehensible.
> > Perhaps it was good in the eighties.  It continues forever.  Consider
> > "face customisation" for instance, which just means font.  Nobody
> > fuckin reads a manual with 17 nodes.  You don't know which one to use,
> > which commands are most useful, and so on.  The problem gets compounded
> > because every esoteric command is there.
> >
> > You are just insisting on something bad and inefficient.
>
> Fair warning: if that is your attitude towards our documentation,
> please be aware that there will be some people here who'd refrain from
> helping you.  We don't work for you, so if you refuse to help yourself
> by becoming more proficient with the extensive documentation features
> in Emacs, we cannot be expected to hold your hand forever.

It is well known that some at Gnu cannot take criticisms when others
try to read what others write.  I am a writer by profession.  So spare
me the "Don't work for you" defensive approach.

Re: Auto Fill Comments

[Robert Pluim]

Christopher Dimech <dimech@gmx.com> writes:

>> From: "Eli Zaretskii" <eliz@gnu.org>
>>
>> Fair warning: if that is your attitude towards our documentation,
>> please be aware that there will be some people here who'd refrain from
>> helping you.  We don't work for you, so if you refuse to help yourself
>> by becoming more proficient with the extensive documentation features
>> in Emacs, we cannot be expected to hold your hand forever.
>
> It is well known that some at Gnu cannot take criticisms when others
> try to read what others write.  I am a writer by profession.  So spare
> me the "Don't work for you" defensive approach.

There is someone in this thread reacting badly to suggestions, and
itʼs not Eli.

People have offered you advice on how to improve your
understanding by reading the extensive and incredibly high quality
documentation that comes with Emacs. You donʼt have to follow that
advice, but continually expecting others to expend their time because
of your failure to attempt to educate yourself is not a winning
strategy.

Robert

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 9:11 AM
> From: "Robert Pluim" <rpluim@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
> 
> >> From: "Eli Zaretskii" <eliz@gnu.org>
> >>
> >> Fair warning: if that is your attitude towards our documentation,
> >> please be aware that there will be some people here who'd refrain from
> >> helping you.  We don't work for you, so if you refuse to help yourself
> >> by becoming more proficient with the extensive documentation features
> >> in Emacs, we cannot be expected to hold your hand forever.
> >
> > It is well known that some at Gnu cannot take criticisms when others
> > try to read what others write.  I am a writer by profession.  So spare
> > me the "Don't work for you" defensive approach.
> 
> There is someone in this thread reacting badly to suggestions, and
> itʼs not Eli.
> 
> People have offered you advice on how to improve your
> understanding by reading the extensive and incredibly high quality
> documentation that comes with Emacs. You donʼt have to follow that
> advice, but continually expecting others to expend their time because
> of your failure to attempt to educate yourself is not a winning
> strategy.
 
> Robert
 
Whenever one mentions a problem it is a user failure.  Yet when there
is a problem with the code you try to address it.  This cannot be 
explained simply.  Perhaps in ten years time, the attitude will change.

Re: Auto Fill Comments

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Fri, 27 Nov 2020 08:59:02 +0100
> Sensitivity: Normal
> 
> 
> > Sent: Friday, November 27, 2020 at 8:28 AM
> > From: "Eli Zaretskii" <eliz@gnu.org>
> > To: help-gnu-emacs@gnu.org
> > Subject: Re: Auto Fill Comments
> >
> > > From: Christopher Dimech <dimech@gmx.com>
> > > Date: Fri, 27 Nov 2020 01:47:08 +0100
> > > Sensitivity: Normal
> > > Cc: help-gnu-emacs@gnu.org
> > >
> > > The manuals should be rewritten because they are incomprehensible.
> > > Perhaps it was good in the eighties.  It continues forever.  Consider
> > > "face customisation" for instance, which just means font.  Nobody
> > > fuckin reads a manual with 17 nodes.  You don't know which one to use,
> > > which commands are most useful, and so on.  The problem gets compounded
> > > because every esoteric command is there.
> > >
> > > You are just insisting on something bad and inefficient.
> >
> > Fair warning: if that is your attitude towards our documentation,
> > please be aware that there will be some people here who'd refrain from
> > helping you.  We don't work for you, so if you refuse to help yourself
> > by becoming more proficient with the extensive documentation features
> > in Emacs, we cannot be expected to hold your hand forever.
> 
> It is well known that some at Gnu cannot take criticisms when others
> try to read what others write.

"I won't read your stuff because it's incomprehensible" is not a valid
criticism.  Criticism implies that you want to improve something, not
disregard it summarily.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 9:25 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: help-gnu-emacs@gnu.org
> > Date: Fri, 27 Nov 2020 08:59:02 +0100
> > Sensitivity: Normal
> >
> >
> > > Sent: Friday, November 27, 2020 at 8:28 AM
> > > From: "Eli Zaretskii" <eliz@gnu.org>
> > > To: help-gnu-emacs@gnu.org
> > > Subject: Re: Auto Fill Comments
> > >
> > > > From: Christopher Dimech <dimech@gmx.com>
> > > > Date: Fri, 27 Nov 2020 01:47:08 +0100
> > > > Sensitivity: Normal
> > > > Cc: help-gnu-emacs@gnu.org
> > > >
> > > > The manuals should be rewritten because they are incomprehensible.
> > > > Perhaps it was good in the eighties.  It continues forever.  Consider
> > > > "face customisation" for instance, which just means font.  Nobody
> > > > fuckin reads a manual with 17 nodes.  You don't know which one to use,
> > > > which commands are most useful, and so on.  The problem gets compounded
> > > > because every esoteric command is there.
> > > >
> > > > You are just insisting on something bad and inefficient.
> > >
> > > Fair warning: if that is your attitude towards our documentation,
> > > please be aware that there will be some people here who'd refrain from
> > > helping you.  We don't work for you, so if you refuse to help yourself
> > > by becoming more proficient with the extensive documentation features
> > > in Emacs, we cannot be expected to hold your hand forever.
> >
> > It is well known that some at Gnu cannot take criticisms when others
> > try to read what others write.
>
> "I won't read your stuff because it's incomprehensible" is not a valid
> criticism.  Criticism implies that you want to improve something, not
> disregard it summarily.

Did not say I won't read.  I read it.

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Friday, November 27, 2020 at 8:28 AM
>> From: "Eli Zaretskii" <eliz@gnu.org>
>> To: help-gnu-emacs@gnu.org
>> Subject: Re: Auto Fill Comments
>>
>> > From: Christopher Dimech <dimech@gmx.com>
>> > Date: Fri, 27 Nov 2020 01:47:08 +0100
>> > Sensitivity: Normal
>> > Cc: help-gnu-emacs@gnu.org
>> >
>> > The manuals should be rewritten because they are incomprehensible.
>> > Perhaps it was good in the eighties.  It continues forever.  Consider
>> > "face customisation" for instance, which just means font.  Nobody
>> > fuckin reads a manual with 17 nodes.  You don't know which one to use,
>> > which commands are most useful, and so on.  The problem gets compounded
>> > because every esoteric command is there.
>> >
>> > You are just insisting on something bad and inefficient.
>>
>> Fair warning: if that is your attitude towards our documentation,
>> please be aware that there will be some people here who'd refrain from
>> helping you.  We don't work for you, so if you refuse to help yourself
>> by becoming more proficient with the extensive documentation features
>> in Emacs, we cannot be expected to hold your hand forever.
>
> It is well known that some at Gnu cannot take criticisms when others
> try to read what others write.  I am a writer by profession.  So spare
> me the "Don't work for you" defensive approach.
I already hinted you that you could hire a professional writer to clean
the swamp for you. Why do you think I told you that? :D

Nobody here works for you. Not Eli, nor everybody else.

Believe me, Emacs documentation is not the problem. You maybe are
writer, but you are certainly not a programmer; otherwise you wouldn't
ask how to start a Java application :-). We all have strengths and
weaknesses; your strength is obviously not programming. Nothing shame in
that, not everybody has to be a programmer.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 9:51 AM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> >> Sent: Friday, November 27, 2020 at 8:28 AM
> >> From: "Eli Zaretskii" <eliz@gnu.org>
> >> To: help-gnu-emacs@gnu.org
> >> Subject: Re: Auto Fill Comments
> >>
> >> > From: Christopher Dimech <dimech@gmx.com>
> >> > Date: Fri, 27 Nov 2020 01:47:08 +0100
> >> > Sensitivity: Normal
> >> > Cc: help-gnu-emacs@gnu.org
> >> >
> >> > The manuals should be rewritten because they are incomprehensible.
> >> > Perhaps it was good in the eighties.  It continues forever.  Consider
> >> > "face customisation" for instance, which just means font.  Nobody
> >> > fuckin reads a manual with 17 nodes.  You don't know which one to use,
> >> > which commands are most useful, and so on.  The problem gets compounded
> >> > because every esoteric command is there.
> >> >
> >> > You are just insisting on something bad and inefficient.
> >>
> >> Fair warning: if that is your attitude towards our documentation,
> >> please be aware that there will be some people here who'd refrain from
> >> helping you.  We don't work for you, so if you refuse to help yourself
> >> by becoming more proficient with the extensive documentation features
> >> in Emacs, we cannot be expected to hold your hand forever.
> >
> > It is well known that some at Gnu cannot take criticisms when others
> > try to read what others write.  I am a writer by profession.  So spare
> > me the "Don't work for you" defensive approach.
> I already hinted you that you could hire a professional writer to clean
> the swamp for you. Why do you think I told you that? :D
>
> Nobody here works for you. Not Eli, nor everybody else.
>
> Believe me, Emacs documentation is not the problem. You maybe are
> writer, but you are certainly not a programmer; otherwise you wouldn't
> ask how to start a Java application :-). We all have strengths and
> weaknesses; your strength is obviously not programming. Nothing shame in
> that, not everybody has to be a programmer.

The programming craft is in the source code.  The documentation is to help
understand it.  Could be even harder than writing the code.  It makes a
convenient listing if you know what you're doing.  It's not always the failure
of readers.

Re: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-11-27 12:25]:
> The programming craft is in the source code.  The documentation is to help
> understand it.  Could be even harder than writing the code.  It makes a
> convenient listing if you know what you're doing.  It's not always the failure
> of readers.

On that last sentence that is so. It is not always the failure of
readers. For instructional manuals of any kind, within or without
Emacs or computing, I think that reader shall be qualified or
qualification level shall be stated before reading it.

Books for young toddlers may be written on thick paper as that is
appropriate. Teenagers read pretty complex biology or have science
books, but definitely not as complex as the same subject of science at
some university.

Emacs is not beginner editor. It is not simple or plain editor. It is
advanced editor and it is meant for advanced human editors. So the
manual is also meant for advanced human editors.

The Emacs Editor
****************

Emacs is the advanced, extensible, customizable, self-documenting
editor.

There is just one problem with that. How can user become advance human
editor if one does not use Emacs already? Or does not get access to
quality Emacs manual?

That is how we get advanced users and those who are yet to become.

Re: Auto Fill Comments

[tomas]

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

On Fri, Nov 27, 2020 at 04:44:32PM +0300, Jean Louis wrote:
> * Christopher Dimech <dimech@gmx.com> [2020-11-27 12:25]:
> > The programming craft is in the source code.  The documentation is to help
> > understand it.  Could be even harder than writing the code.  It makes a
> > convenient listing if you know what you're doing.  It's not always the failure
> > of readers.
> 
> On that last sentence that is so. It is not always the failure of
> readers [...]

Most definitely not. But when I find myself paraphrasing (badly, at
that) what's already written in the manual, I've to step back and
ask myself whether I'm doing anything wrong.

Cheers
 - t

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

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 5:02 PM
> From: tomas@tuxteam.de
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Fri, Nov 27, 2020 at 04:44:32PM +0300, Jean Louis wrote:
> > * Christopher Dimech <dimech@gmx.com> [2020-11-27 12:25]:
> > > The programming craft is in the source code.  The documentation is to help
> > > understand it.  Could be even harder than writing the code.  It makes a
> > > convenient listing if you know what you're doing.  It's not always the failure
> > > of readers.
> >
> > On that last sentence that is so. It is not always the failure of
> > readers [...]
>
> Most definitely not. But when I find myself paraphrasing (badly, at
> that) what's already written in the manual, I've to step back and
> ask myself whether I'm doing anything wrong.

You tried to explain it better, but think the wording in the manual
described things better.  Nothing wrong about that.  Thank you for
trying to clarify things.  Also, there is nothing wrong with giving
up.  I was just saying how it was for me, that's all.

As more people get to use emacs, what was adequate before, becomes
inadequate.  Many things will change and people would want to use it
in different ways and at different levels of sophistication.  A
possibility could be not about writing more, but organise better.

After all we want that others are pleased with our work.

Regards
Christopher



> Cheers
>  - t
>

Re: Auto Fill Comments

[tomas]

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

On Fri, Nov 27, 2020 at 06:41:44PM +0100, Christopher Dimech wrote:
> 
> > Sent: Friday, November 27, 2020 at 5:02 PM
> > From: tomas@tuxteam.de

[...]

> > > On that last sentence that is so. It is not always the failure of
> > > readers [...]
> >
> > Most definitely not.

To clarify: I think trying to think of this as the "failure of some
person" is an error. It's a failure of communication.

>                        But when I find myself paraphrasing (badly, at
> > that) what's already written in the manual, I've to step back and
> > ask myself whether I'm doing anything wrong.
> 
> You tried to explain it better, but think the wording in the manual
> described things better.

This was my realisation, too :)

>                            Nothing wrong about that.  Thank you for
> trying to clarify things.  Also, there is nothing wrong with giving
> up.  I was just saying how it was for me, that's all.

I'm not giving up. Just stepping back to think. Your input helps,
appreciated.

> As more people get to use emacs, what was adequate before, becomes
> inadequate.

Sometimes it's just difficult to wrap one's head around things.
"Local" variables with different kinds of locality is one of
those, but they are there for a reason. Life in Emacs without
buffer-local variables would be way more difficult.

Imagine the mess a complex mode (like CC mode) would be if you
always had to consult some buffer-bound data structure instead
of having buffer-local variables disguised as "globals".

Imagine the organizational mess minor modes would be.

Now my head hurts :)

>             Many things will change and people would want to use it
> in different ways and at different levels of sophistication.  A
> possibility could be not about writing more, but organise better.
> 
> After all we want that others are pleased with our work.

Definitely.

Cheers
 - t

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

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 6:53 PM
> From: tomas@tuxteam.de
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Fri, Nov 27, 2020 at 06:41:44PM +0100, Christopher Dimech wrote:
> >
> > > Sent: Friday, November 27, 2020 at 5:02 PM
> > > From: tomas@tuxteam.de
>
> [...]
>
> > > > On that last sentence that is so. It is not always the failure of
> > > > readers [...]
> > >
> > > Most definitely not.
>
> To clarify: I think trying to think of this as the "failure of some
> person" is an error. It's a failure of communication.
>
> >                        But when I find myself paraphrasing (badly, at
> > > that) what's already written in the manual, I've to step back and
> > > ask myself whether I'm doing anything wrong.
> >
> > You tried to explain it better, but think the wording in the manual
> > described things better.
>
> This was my realisation, too :)
>
> >                            Nothing wrong about that.  Thank you for
> > trying to clarify things.  Also, there is nothing wrong with giving
> > up.  I was just saying how it was for me, that's all.
>
> I'm not giving up. Just stepping back to think. Your input helps,
> appreciated.
>
> > As more people get to use emacs, what was adequate before, becomes
> > inadequate.
>
> Sometimes it's just difficult to wrap one's head around things.
> "Local" variables with different kinds of locality is one of
> those, but they are there for a reason. Life in Emacs without
> buffer-local variables would be way more difficult.

My experience has been that as I got to do more things in emacs lisp,
the understanding needed quickly exceeded my rate of learning.
One can get to sophisticated constructs, even when trying to do
relatively simple things.  You never know where your original
plan could get you. Many times the importance of a work is not
measured by its consequences (i.e. by the final command).


> Imagine the mess a complex mode (like CC mode) would be if you
> always had to consult some buffer-bound data structure instead
> of having buffer-local variables disguised as "globals".
>
> Imagine the organizational mess minor modes would be.
>
> Now my head hurts :)
>
> >             Many things will change and people would want to use it
> > in different ways and at different levels of sophistication.  A
> > possibility could be not about writing more, but organise better.
> >
> > After all we want that others are pleased with our work.
>
> Definitely.
>
> Cheers
>  - t
>

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 7:07 PM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: tomas@tuxteam.de
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
>
> > Sent: Friday, November 27, 2020 at 6:53 PM
> > From: tomas@tuxteam.de
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: help-gnu-emacs@gnu.org
> > Subject: Re: Auto Fill Comments
> >
> > On Fri, Nov 27, 2020 at 06:41:44PM +0100, Christopher Dimech wrote:
> > >
> > > > Sent: Friday, November 27, 2020 at 5:02 PM
> > > > From: tomas@tuxteam.de
> >
> > [...]
> >
> > > > > On that last sentence that is so. It is not always the failure of
> > > > > readers [...]
> > > >
> > > > Most definitely not.
> >
> > To clarify: I think trying to think of this as the "failure of some
> > person" is an error. It's a failure of communication.
> >
> > >                        But when I find myself paraphrasing (badly, at
> > > > that) what's already written in the manual, I've to step back and
> > > > ask myself whether I'm doing anything wrong.
> > >
> > > You tried to explain it better, but think the wording in the manual
> > > described things better.
> >
> > This was my realisation, too :)
> >
> > >                            Nothing wrong about that.  Thank you for
> > > trying to clarify things.  Also, there is nothing wrong with giving
> > > up.  I was just saying how it was for me, that's all.
> >
> > I'm not giving up. Just stepping back to think. Your input helps,
> > appreciated.
> >
> > > As more people get to use emacs, what was adequate before, becomes
> > > inadequate.
> >
> > Sometimes it's just difficult to wrap one's head around things.
> > "Local" variables with different kinds of locality is one of
> > those, but they are there for a reason. Life in Emacs without
> > buffer-local variables would be way more difficult.
>
> My experience has been that as I got to do more things in emacs lisp,
> the understanding needed quickly exceeded my rate of learning.
> One can get to sophisticated constructs, even when trying to do
> relatively simple things.  You never know where your original
> plan could get you. Many times the importance of a work is not
> measured by its consequences (i.e. by the final command).
>
>
> > Imagine the mess a complex mode (like CC mode) would be if you
> > always had to consult some buffer-bound data structure instead
> > of having buffer-local variables disguised as "globals".
> >
> > Imagine the organizational mess minor modes would be.
> >
> > Now my head hurts :)
> >
> > >             Many things will change and people would want to use it
> > > in different ways and at different levels of sophistication.  A
> > > possibility could be not about writing more, but organise better.

This is what has to be understood - Gnu needs to start thinking about
having different levels of sophistication within its packages.  Historically,
it has always been about the end result. As long as things work people were
satisfied.  It sounds reasonable from the surface, but quite problematic after
one introspects the subsurface.

Regards
Christopher

> > > After all we want that others are pleased with our work.
> >
> > Definitely.
> >
> > Cheers
> >  - t
> >
>
>

Re: Auto Fill Comments

[tomas]

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

On Fri, Nov 27, 2020 at 07:45:02PM +0100, Christopher Dimech wrote:

[...]

> This is what has to be understood - Gnu needs to start thinking about
> having different levels of sophistication within its packages [...]

At least, in the doc, work has gone into it. Cf. the Emacs Lisp intro:

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

As always, also in an info file near you (hopefully :)

Cheers
 - t

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

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 10:16 PM
> From: tomas@tuxteam.de
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Fri, Nov 27, 2020 at 07:45:02PM +0100, Christopher Dimech wrote:
>
> [...]
>
> > This is what has to be understood - Gnu needs to start thinking about
> > having different levels of sophistication within its packages [...]
>
> At least, in the doc, work has gone into it. Cf. the Emacs Lisp intro:
>
>   https://www.gnu.org/software/emacs/manual/html_mono/eintr.html

But not only, also in the code.  So that those studying the source
don't get confronted with whatever type of sophistication the authors
settled for.  Perhaps a tagging system on files so others can know what's
required to understand.  If most have high level of sophistication,
it could be a problem that went unnoticed whilst changes were being done.

I know that Jose Marchesi did some work on extracting the Cyclomatic
Complexity from source code.

> As always, also in an info file near you (hopefully :)
>
> Cheers
>  - t
>

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

> My experience has been that as I got to do more things in emacs lisp,
> the understanding needed quickly exceeded my rate of learning.
> One can get to sophisticated constructs, even when trying to do
> relatively simple things.  You never know where your original
> plan could get you. Many times the importance of a work is not
> measured by its consequences (i.e. by the final command).
That is probably because you try to do more difficult things then
before.

I have been using Emacs for like almost 20 years, and was enough with
setq-ing few variables, and wrapping ocassional few lines in a defun to
put it on a hook.

Then when I tried to do something more advanced, I realized I was
hitting a wall and that my knowledge was too lacking; I didn't even know
how to read and parse a file with Elisp one year ago; and I wrote a toy
compiler 20 years ago.

I never needed to learn Lisp, and I knew there are probably lots of
idiomatic things I need to before I can do anything interesting with
it. 

It is just to accept what we don't know; and I realized I would
need a time to learn it. Thinking that one can just look up all relevant
things in instant is a misstake. Becomming fluent with ani API and
programming language takes time. Lisp, PHP and TCL are ones that I found
easiest to learn, yet it takes lot of time to learn all the APIs, how
they are used, all the fine details etc.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 8:03 PM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > My experience has been that as I got to do more things in emacs lisp,
> > the understanding needed quickly exceeded my rate of learning.
> > One can get to sophisticated constructs, even when trying to do
> > relatively simple things.  You never know where your original
> > plan could get you. Many times the importance of a work is not
> > measured by its consequences (i.e. by the final command).
> That is probably because you try to do more difficult things then
> before.
>
> I have been using Emacs for like almost 20 years, and was enough with
> setq-ing few variables, and wrapping ocassional few lines in a defun to
> put it on a hook.

I used to argue that code must be adequately commented.  Later on I realised
that adequacy is determined by the skill of the reader.  Currently I advocate
that code comments are to give an overview of the code to help you reduce
the downtime required to work on the code after a time of inactivity.

Documentation, however, is to be structured according to different levels
of sophistication.  But I understand it could be a lot of work to complete.
Was not my intention to deride anyone. but to describe how it is.  Documentation
is always better than no documentation.  And everyone does as one can.

> Then when I tried to do something more advanced, I realized I was
> hitting a wall and that my knowledge was too lacking; I didn't even know
> how to read and parse a file with Elisp one year ago; and I wrote a toy
> compiler 20 years ago.
>
> I never needed to learn Lisp, and I knew there are probably lots of
> idiomatic things I need to before I can do anything interesting with
> it.
>
> It is just to accept what we don't know; and I realized I would
> need a time to learn it. Thinking that one can just look up all relevant
> things in instant is a misstake. Becomming fluent with ani API and
> programming language takes time. Lisp, PHP and TCL are ones that I found
> easiest to learn, yet it takes lot of time to learn all the APIs, how
> they are used, all the fine details etc.
>
>

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Friday, November 27, 2020 at 8:03 PM
>> From: "Arthur Miller" <arthur.miller@live.com>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: help-gnu-emacs@gnu.org
>> Subject: Re: Auto Fill Comments
>>
>> Christopher Dimech <dimech@gmx.com> writes:
>>
>> > My experience has been that as I got to do more things in emacs lisp,
>> > the understanding needed quickly exceeded my rate of learning.
>> > One can get to sophisticated constructs, even when trying to do
>> > relatively simple things.  You never know where your original
>> > plan could get you. Many times the importance of a work is not
>> > measured by its consequences (i.e. by the final command).
>> That is probably because you try to do more difficult things then
>> before.
>>
>> I have been using Emacs for like almost 20 years, and was enough with
>> setq-ing few variables, and wrapping ocassional few lines in a defun to
>> put it on a hook.
>
> I used to argue that code must be adequately commented.  Later on I realised
> that adequacy is determined by the skill of the reader.  Currently I advocate
> that code comments are to give an overview of the code to help you reduce
> the downtime required to work on the code after a time of inactivity.
>
> Documentation, however, is to be structured according to different levels
> of sophistication.  But I understand it could be a lot of work to complete.
> Was not my intention to deride anyone. but to describe how it is.  Documentation
> is always better than no documentation.  And everyone does as one can.

True. However, Emacs manuals are written by volunteers with limited
resources in their spair time (I hack Emacs as a hobby when I drink
coffee), so what is practical has also to be take into account. They
have to prioritize what level they put themselves on, especially Elisp
manual.

I think it currently has good balance between targetting basics and
advanced usage.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 10:26 PM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> >> Sent: Friday, November 27, 2020 at 8:03 PM
> >> From: "Arthur Miller" <arthur.miller@live.com>
> >> To: "Christopher Dimech" <dimech@gmx.com>
> >> Cc: help-gnu-emacs@gnu.org
> >> Subject: Re: Auto Fill Comments
> >>
> >> Christopher Dimech <dimech@gmx.com> writes:
> >>
> >> > My experience has been that as I got to do more things in emacs lisp,
> >> > the understanding needed quickly exceeded my rate of learning.
> >> > One can get to sophisticated constructs, even when trying to do
> >> > relatively simple things.  You never know where your original
> >> > plan could get you. Many times the importance of a work is not
> >> > measured by its consequences (i.e. by the final command).
> >> That is probably because you try to do more difficult things then
> >> before.
> >>
> >> I have been using Emacs for like almost 20 years, and was enough with
> >> setq-ing few variables, and wrapping ocassional few lines in a defun to
> >> put it on a hook.
> >
> > I used to argue that code must be adequately commented.  Later on I realised
> > that adequacy is determined by the skill of the reader.  Currently I advocate
> > that code comments are to give an overview of the code to help you reduce
> > the downtime required to work on the code after a time of inactivity.
> >
> > Documentation, however, is to be structured according to different levels
> > of sophistication.  But I understand it could be a lot of work to complete.
> > Was not my intention to deride anyone. but to describe how it is.  Documentation
> > is always better than no documentation.  And everyone does as one can.
>
> True. However, Emacs manuals are written by volunteers with limited
> resources in their spair time (I hack Emacs as a hobby when I drink
> coffee), so what is practical has also to be take into account. They
> have to prioritize what level they put themselves on, especially Elisp
> manual.

Agreed.  But telling users that one does not work for them is excessive, to say
the least.  I have hired people to work on free software, not one or two.
And things were approached more professionally.  Those in such position to assign
work will think twice before assigning someone to the task if they come across
the wrong way.  I certainly do.

> I think it currently has good balance between targetting basics and
> advanced usage.
>
>

Re: Auto Fill Comments

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> Agreed.  But telling users that one does not work for them is
> excessive, to say the least.

Taking care of this manual is excessive.  I have much respect for
the work Eli is doing.

You can never write a manual that fits everyone's expectations.  It fits
mine quite well.  Yours not, obviously.

But guess you are working on that manual over years, for thousands of
hours probably.  Say, 90% of people like it, and 10 % don't like it.
What you get is that these 90% post, "hey, I've read that manual, it was
great" and eh - no, ehm, they say... nothing, you seldom hear from them;
and 10% don't like it and are frustrated and tell you it sucks, please
rewrite.  They didn't really read it and don't really know what they are
talking about because they can't estimate what it covers and why.

And if you ask for help everybody is suddenly quiet.  I would be pissed
off.  I don't know where Eli's motivation comes from.

Michael.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 11:15 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Agreed.  But telling users that one does not work for them is
> > excessive, to say the least.
>
> Taking care of this manual is excessive.  I have much respect for
> the work Eli is doing.

Quite correct, got to be a group effort.  We can only write on things we understand.
Yes, writing takes a lot of time.  Never said he should do it all personally.  But
as he is the maintainer, he can put that on the todo list and make that public.

> You can never write a manual that fits everyone's expectations.  It fits
> mine quite well.  Yours not, obviously.

It fits up to a certain level.  In source code it is more problematic as
the first try has always been to get to a solution and do it quickly.

I know some who started to work on something else out of frustration,
or because they found code which is too complicated.  I am talking about
extremely bright people here (e.g. Guy Steele, Rich Hickey, Carsten Dominik,
Linus Torvalds).

> But guess you are working on that manual over years, for thousands of
> hours probably.  Say, 90% of people like it, and 10 % don't like it.
> What you get is that these 90% post, "hey, I've read that manual, it was
> great" and eh - no, ehm, they say... nothing, you seldom hear from them;
> and 10% don't like it and are frustrated and tell you it sucks, please
> rewrite.  They didn't really read it and don't really know what they are
> talking about because they can't estimate what it covers and why.
>
> And if you ask for help everybody is suddenly quiet.  I would be pissed
> off.  I don't know where Eli's motivation comes from.
>
> Michael.
>
>
>

Re: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-11-28 01:39]:
> I know some who started to work on something else out of frustration,
> or because they found code which is too complicated.  I am talking about
> extremely bright people here (e.g. Guy Steele, Rich Hickey, Carsten Dominik,
> Linus Torvalds).

Only them start to code out of frustration?

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Saturday, November 28, 2020 at 2:06 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Michael Heerdegen" <michael_heerdegen@web.de>, help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> * Christopher Dimech <dimech@gmx.com> [2020-11-28 01:39]:
> > I know some who started to work on something else out of frustration,
> > or because they found code which is too complicated.  I am talking about
> > extremely bright people here (e.g. Guy Steele, Rich Hickey, Carsten Dominik,
> > Linus Torvalds).
>
> Only them start to code out of frustration?

Am continuing with elisp, so not so defeated yet.

>

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 11:15 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Agreed.  But telling users that one does not work for them is
> > excessive, to say the least.
>
> Taking care of this manual is excessive.  I have much respect for
> the work Eli is doing.
>
> You can never write a manual that fits everyone's expectations.  It fits
> mine quite well.  Yours not, obviously.
>
> But guess you are working on that manual over years, for thousands of
> hours probably.  Say, 90% of people like it, and 10 % don't like it.
> What you get is that these 90% post, "hey, I've read that manual, it was
> great" and eh - no, ehm, they say... nothing, you seldom hear from them;
> and 10% don't like it and are frustrated and tell you it sucks, please
> rewrite.  They didn't really read it and don't really know what they are
> talking about because they can't estimate what it covers and why.
>
> And if you ask for help everybody is suddenly quiet.

Yes, that can be problematic.  I am the founder of an Official
Gnu Package myself.  So I'm not here just to rant.  I will write
an emacs lisp manual for users who know some lisp and would like
something to chew on that they can manage.  Somehow, freedom
respecting software must became part of formal work.  The fact
that after all these years it has not means we are basically doing
things wrong.  Yet, on the International Space Station, it has became
formal work.  I know because I worked with the Solar Dynamics
Observatory back in 2010 and now in Submarine Surveillance.

> I would be pissed
> off.  I don't know where Eli's motivation comes from.
>
> Michael.
>
>
>

Re: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-11-28 01:58]:
> Yes, that can be problematic.  I am the founder of an Official
> Gnu Package myself.  So I'm not here just to rant.  I will write
> an emacs lisp manual for users who know some lisp and would like
> something to chew on that they can manage.  Somehow, freedom
> respecting software must became part of formal work.  The fact
> that after all these years it has not means we are basically doing
> things wrong.  Yet, on the International Space Station, it has became
> formal work.  I know because I worked with the Solar Dynamics
> Observatory back in 2010 and now in Submarine Surveillance.

Please keep official government secrets secret that this mailing list
does not get seized.

Re: Auto Fill Comments

[Christopher Dimech]

Felicitations.  I have started people on emacs here actually.  I could even
invite some people over if it was not for the pandemic.  Have you ever been
to Monterey?

Regards
Christopher

---------------------
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: Saturday, November 28, 2020 at 2:08 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Michael Heerdegen" <michael_heerdegen@web.de>, help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> * Christopher Dimech <dimech@gmx.com> [2020-11-28 01:58]:
> > Yes, that can be problematic.  I am the founder of an Official
> > Gnu Package myself.  So I'm not here just to rant.  I will write
> > an emacs lisp manual for users who know some lisp and would like
> > something to chew on that they can manage.  Somehow, freedom
> > respecting software must became part of formal work.  The fact
> > that after all these years it has not means we are basically doing
> > things wrong.  Yet, on the International Space Station, it has became
> > formal work.  I know because I worked with the Solar Dynamics
> > Observatory back in 2010 and now in Submarine Surveillance.
>
> Please keep official government secrets secret that this mailing list
> does not get seized.
>
>

Re: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-11-28 04:45]:
> Felicitations.  I have started people on emacs here actually.  I could even
> invite some people over if it was not for the pandemic.  Have you ever been
> to Monterey?

Not yet, and that is great for starting people.

Re: Auto Fill Comments

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Fri, 27 Nov 2020 23:15:58 +0100
> 
> And if you ask for help everybody is suddenly quiet.  I would be pissed
> off.  I don't know where Eli's motivation comes from.

My motivation comes from the urge to keep improving the Emacs
documentation.  I cannot possibly do that with "criticism" that just
says our documentation sucks and should be rewritten, because that's
not useful: I don't know how to convert that to any useful list of
things to fix.

And, of course, saying that the manuals should be rewritten is a clear
sign that the person probably doesn't know how to use the Info mode
efficiently, and probably didn't read too much of said documentation.
Which further diminishes the useful payload of such claims.

Re: Auto Fill Comments

[Christopher Dimech]

Re-Writing is a basic tenet amongst writers, but not among programmers it seems.


> Sent: Saturday, November 28, 2020 at 8:46 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Date: Fri, 27 Nov 2020 23:15:58 +0100
> >
> > And if you ask for help everybody is suddenly quiet.  I would be pissed
> > off.  I don't know where Eli's motivation comes from.
>
> My motivation comes from the urge to keep improving the Emacs
> documentation.  I cannot possibly do that with "criticism" that just
> says our documentation sucks and should be rewritten, because that's
> not useful: I don't know how to convert that to any useful list of
> things to fix.
>
> And, of course, saying that the manuals should be rewritten is a clear
> sign that the person probably doesn't know how to use the Info mode
> efficiently, and probably didn't read too much of said documentation.
> Which further diminishes the useful payload of such claims.
>
>

Re: Auto Fill Comments

[Andy Moreton]

On Sat 28 Nov 2020, Christopher Dimech wrote:

> Re-Writing is a basic tenet amongst writers, but not among programmers it seems.
>

You will gain a warmer reception from people who are volunteering their
time to assist you if you drop the attitude.

Your critique is not constructive. Please express your difficulty with
the documentation by making specific suggestions to improve it.

    AndyM

Re: Auto Fill Comments

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Sat, 28 Nov 2020 13:05:47 +0100
> 
> Re-Writing is a basic tenet amongst writers, but not among programmers it seems.

The 2 Emacs manuals weigh in at almost 2000 pages of printed text.
Rewriting that is a Gargantuan task that is hardly justified in this
case.

Re: Auto Fill Comments

[Christopher Dimech]

It was simply to think about it when people are doing work on the manual.
It is more about "An Introduction to Programming in Emacs Lisp". And perhaps
something at intermediate level when people got time.  Have been looking
at making a small elisp package to learn but still keep commands at a basic
level.  Then build from there.  And because I would be the author, I will
see how it is to be in your situation with respect to manuals.  I have written
very long works myself.

I can start with my group and see how they get along with it.  Would be good
to make a tutorial about it.

Regards
C*
> Sent: Saturday, November 28, 2020 at 5:15 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: help-gnu-emacs@gnu.org
> > Date: Sat, 28 Nov 2020 13:05:47 +0100
> >
> > Re-Writing is a basic tenet amongst writers, but not among programmers it seems.
>
> The 2 Emacs manuals weigh in at almost 2000 pages of printed text.
> Rewriting that is a Gargantuan task that is hardly justified in this
> case.
>
>

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

> Re-Writing is a basic tenet amongst writers, but not among programmers it seems.
 :-) Plagiators who can't come up with new ideas ;-)

If Hemingway rewrote as much as programmers do, the old man would  still
be deciding which oars to choose for todays fishing. 

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Sunday, November 29, 2020 at 1:08 AM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Re-Writing is a basic tenet amongst writers, but not among programmers it seems.
>  :-) Plagiators who can't come up with new ideas ;-)

I remember the time I copied A Farewell To Arms in its entirety on a typewriter
in order to learn about his writing style and how it feels to write a great
work.

> If Hemingway rewrote as much as programmers do, the old man would  still
> be deciding which oars to choose for todays fishing.

You forgot about Stephen King.  The man's a legend.

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Sunday, November 29, 2020 at 1:08 AM
>> From: "Arthur Miller" <arthur.miller@live.com>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: help-gnu-emacs@gnu.org
>> Subject: Re: Auto Fill Comments
>>
>> Christopher Dimech <dimech@gmx.com> writes:
>>
>> > Re-Writing is a basic tenet amongst writers, but not among programmers it seems.
>>  :-) Plagiators who can't come up with new ideas ;-)
>
> I remember the time I copied A Farewell To Arms in its entirety on a typewriter
> in order to learn about his writing style and how it feels to write a great
> work.
>
>> If Hemingway rewrote as much as programmers do, the old man would  still
>> be deciding which oars to choose for todays fishing.
>
> You forgot about Stephen King.  The man's a legend.
I don't have time for guys like Stephen King; too much Lisp left to
read. Still didn't red all Plato's dialogues I had on my todo.

If you want different introduction into Lisp and can stad awful english,
you might look here: https://github.com/amno1/as-powerful-as-possible

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Sunday, November 29, 2020 at 1:25 AM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> >> Sent: Sunday, November 29, 2020 at 1:08 AM
> >> From: "Arthur Miller" <arthur.miller@live.com>
> >> To: "Christopher Dimech" <dimech@gmx.com>
> >> Cc: help-gnu-emacs@gnu.org
> >> Subject: Re: Auto Fill Comments
> >>
> >> Christopher Dimech <dimech@gmx.com> writes:
> >>
> >> > Re-Writing is a basic tenet amongst writers, but not among programmers it seems.
> >>  :-) Plagiators who can't come up with new ideas ;-)
> >
> > I remember the time I copied A Farewell To Arms in its entirety on a typewriter
> > in order to learn about his writing style and how it feels to write a great
> > work.
> >
> >> If Hemingway rewrote as much as programmers do, the old man would  still
> >> be deciding which oars to choose for todays fishing.
> >
> > You forgot about Stephen King.  The man's a legend.
> I don't have time for guys like Stephen King; too much Lisp left to
> read. Still didn't red all Plato's dialogues I had on my todo.

> If you want different introduction into Lisp and can stad awful english,
> you might look here: https://github.com/amno1/as-powerful-as-possible

Yep, I suppose one got to see everything.

Currently I have done almost enough lisp to push a release for an emacs setup
besides other things.  Could be useful for those who want to try it out.

Re: Auto Fill Comments

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> You forgot about Stephen King.  The man's a legend.

I wonder how he solves problems with auto filling.

Michael.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Sunday, November 29, 2020 at 2:15 AM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > You forgot about Stephen King.  The man's a legend.
>
> I wonder how he solves problems with auto filling.

Message understood.  Let's go back do some work and perhaps next year I'll
solve it and tell you all about it.  But I wonder how many people would use
to.  Is it really a waste of time?

Regards


> Michael.
>
>
>

Re: Auto Fill Comments

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> > I wonder how he solves problems with auto filling.
>
> Message understood.

There was no message intended, that was just a silly joke.

> Let's go back do some work and perhaps next year I'll solve it and
> tell you all about it.

Solve what? - was there still an open question here?  The discussion has
drifted so far that I got somewhat lost (and that was what my joke was
about).

Regards,

Michael.

Re: Auto Fill Comments

[Christopher Dimech]

Correct.  The thing got out of hand and makes sense to close the discussion.

Was trying to have a keybinding that cycles between three things:

1. Autofill Only Comments
2. Autofill Whole Buffer
3. Revert to No-Autofill

Problem started because I should use buffer-local.  People suggested
I read the manual to figure out what to do.  But couldn't follow things
well enough to come up with something that works.  Probably got to wait
until my skills become good enough to do it.  And then I can update the
manual or publish something myself in a way that is easier than the
information I have read.

I have a different approach about reading and working than the traditional
programmer.  Only read and write as much as needed, nothing more.  But this
did not go well with the purists, who took offense.

That's about it.






> Sent: Sunday, November 29, 2020 at 3:56 AM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > > I wonder how he solves problems with auto filling.
> >
> > Message understood.
>
> There was no message intended, that was just a silly joke.
>
> > Let's go back do some work and perhaps next year I'll solve it and
> > tell you all about it.
>
> Solve what? - was there still an open question here?  The discussion has
> drifted so far that I got somewhat lost (and that was what my joke was
> about).
>
> Regards,
>
> Michael.
>
>
>

Re: Auto Fill Comments

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> Was trying to have a keybinding that cycles between three things:
>
> 1. Autofill Only Comments
> 2. Autofill Whole Buffer
> 3. Revert to No-Autofill
>
> Problem started because I should use buffer-local.  People suggested
> I read the manual to figure out what to do.  But couldn't follow things
> well enough to come up with something that works.

Any specific questions?  About things you didn't understand when
reading?

The basics are simple: You make a variable buffer local in the current
buffer with `make-local-variable'.  Then setting the variable whenever
that buffer is current sets the buffer local binding (in that buffer) of
this variable.  Evaluation of a variable results in the buffer local
value when there is one, else in the global binding.  `default-value' to
return the global binding of a variable regardless of buffer-local
bindings.

See also `setq-local' which makes a variable buffer local in the current
buffer an sets the value at the same time.


Regards,

Michael.

Re: Auto Fill Comments

[Christopher Dimech]

The problem starts with actually trying to do something after deciding to
give elisp a try.  Very often this requires a lot of emacs specific knowledge.
There need to be links with very clear steps.  If you want X, here's how you
do it, geared towards the beginning developer (to elisp, not to development).
For the expert, there are all lots or resources to find information.

---------------------
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: Monday, November 30, 2020 at 12:41 AM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Was trying to have a keybinding that cycles between three things:
> >
> > 1. Autofill Only Comments
> > 2. Autofill Whole Buffer
> > 3. Revert to No-Autofill
> >
> > Problem started because I should use buffer-local.  People suggested
> > I read the manual to figure out what to do.  But couldn't follow things
> > well enough to come up with something that works.
>
> Any specific questions?  About things you didn't understand when
> reading?
>
> The basics are simple: You make a variable buffer local in the current
> buffer with `make-local-variable'.  Then setting the variable whenever
> that buffer is current sets the buffer local binding (in that buffer) of
> this variable.  Evaluation of a variable results in the buffer local
> value when there is one, else in the global binding.  `default-value' to
> return the global binding of a variable regardless of buffer-local
> bindings.
>
> See also `setq-local' which makes a variable buffer local in the current
> buffer an sets the value at the same time.

Thanks Michael.  I will have a go at it this week.

> Regards,
>
> Michael.
>
>
>

Re: Auto Fill Comments

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christopher Dimech wrote:

> The problem starts with actually trying to do something after
> deciding to give elisp a try. Very often this requires a lot of
> emacs specific knowledge. There need to be links with very
> clear steps. If you want X, here's how you do it, geared
> towards the beginning developer (to elisp, not to development).
> For the expert, there are all lots or resources to
> find information.

Like every computer system, there isn't any method except use the
darn thing every day and learn something new every day.

Yes, 365 things a year is plenty enough.

Like my mother, she was in Paris 1968 and there was a campaign in
the subway: "One liter of wine a day is enough"

> ---------------------
> 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

Hint - RFC 3676, section 4.3:

  https://www.ietf.org/rfc/rfc3676.txt

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

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Monday, November 30, 2020 at 2:06 AM
> From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech wrote:
>
> > The problem starts with actually trying to do something after
> > deciding to give elisp a try. Very often this requires a lot of
> > emacs specific knowledge. There need to be links with very
> > clear steps. If you want X, here's how you do it, geared
> > towards the beginning developer (to elisp, not to development).
> > For the expert, there are all lots or resources to
> > find information.
>
> Like every computer system, there isn't any method except use the
> darn thing every day and learn something new every day.

Learning by doing.  Sounds like an episode from M.A.S.H. :)

> Yes, 365 things a year is plenty enough.
>
> Like my mother, she was in Paris 1968 and there was a campaign in
> the subway: "One liter of wine a day is enough"
>
> > ---------------------
> > 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
>
> Hint - RFC 3676, section 4.3:
>
>   https://www.ietf.org/rfc/rfc3676.txt
>
> --
> underground experts united
> http://user.it.uu.se/~embe8573
> https://dataswamp.org/~incal
>
>
>

Re: Auto Fill Comments

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christopher Dimech wrote:

> Learning by doing. Sounds like an episode from M.A.S.H. :)

Let's turn it into McGuyver.

Learning by doing while thinking at the same time!

Know what you have, what they can do.

Individually.

Combined!

After that, your own creativity...

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

Re: Auto Fill Comments

[tomas]

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

On Mon, Nov 30, 2020 at 02:49:37AM +0100, Christopher Dimech wrote:
> 
> > Sent: Monday, November 30, 2020 at 2:06 AM
> > From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> > To: help-gnu-emacs@gnu.org
> > Subject: Re: Auto Fill Comments
> >
> > Christopher Dimech wrote:
> >
> > > The problem starts with actually trying to do something after
> > > deciding to give elisp a try. Very often this requires a lot of
> > > emacs specific knowledge [...]

> > Like every computer system, there isn't any method except use the
> > darn thing every day and learn something new every day.
> 
> Learning by doing.  Sounds like an episode from M.A.S.H. :)

Actually yes, I concur witn Emanuel here. Many human activities (and
the more complex, the merrier) involve a part which might be called
"craft" -- something you can learn only by trying, failing, trying
again. This applies uniformly to proving math theorems, cooking,
driving a bike -- and to bending Emacs to your will.

The manual can't do this part for you :-)

Cheers
 - t

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

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Monday, November 30, 2020 at 9:58 AM
> From: tomas@tuxteam.de
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Mon, Nov 30, 2020 at 02:49:37AM +0100, Christopher Dimech wrote:
> >
> > > Sent: Monday, November 30, 2020 at 2:06 AM
> > > From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> > > To: help-gnu-emacs@gnu.org
> > > Subject: Re: Auto Fill Comments
> > >
> > > Christopher Dimech wrote:
> > >
> > > > The problem starts with actually trying to do something after
> > > > deciding to give elisp a try. Very often this requires a lot of
> > > > emacs specific knowledge [...]
>
> > > Like every computer system, there isn't any method except use the
> > > darn thing every day and learn something new every day.
> >
> > Learning by doing.  Sounds like an episode from M.A.S.H. :)
>
> Actually yes, I concur witn Emanuel here. Many human activities (and
> the more complex, the merrier) involve a part which might be called
> "craft" -- something you can learn only by trying, failing, trying
> again. This applies uniformly to proving math theorems, cooking,
> driving a bike -- and to bending Emacs to your will.
>
> The manual can't do this part for you :-)

Correct.  Still I am working on that and have included it in formal work.
If Gnu work continues to be simply a spare time thing many problems will
arise as we are witnessing.  People can quickly make a comparison, particularly
those working is serious settings but are interested in using free software.
Thumbing them or assume that volunteers have better skills is fundamentally
wrong.  I have encountered this many times on gnu mailing list.  Although,
it is to be said that it is the administrators of the package that actually
set the agenda.

Regards.
C*




> Cheers
>  - t
>

Re: Auto Fill Comments

[tomas]

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

On Mon, Nov 30, 2020 at 11:09:52AM +0100, Christopher Dimech wrote:

[...]

> Correct.  Still I am working on that and have included it in formal work.
> If Gnu work continues to be simply a spare time thing many problems will
> arise as we are witnessing.

I don't know, really. Having seen "paid-for" manuals before, I'd dare
to say that I am spoilt, as an almost-exclusive free software user.

And having been stranded in more than one support hell, superficially
friendly (but you know it's a template, peppered with "user experience"
and things), but they let you know that all is about reducing per-issue
cost (and you /are/ an issue)...

...I seriously prefer the occasional "hey, tomas, go RTFM now" --
although I try, as well as I can, to not inflict that on people.

Cheers
 - t

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

Re: Auto Fill Comments

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2020-11-30 13:42]:
> On Mon, Nov 30, 2020 at 11:09:52AM +0100, Christopher Dimech wrote:
> 
> [...]
> 
> > Correct.  Still I am working on that and have included it in formal work.
> > If Gnu work continues to be simply a spare time thing many problems will
> > arise as we are witnessing.
> 
> I don't know, really. Having seen "paid-for" manuals before, I'd dare
> to say that I am spoilt, as an almost-exclusive free software user.
> 
> And having been stranded in more than one support hell, superficially
> friendly (but you know it's a template, peppered with "user experience"
> and things), but they let you know that all is about reducing per-issue
> cost (and you /are/ an issue)...
> 
> ...I seriously prefer the occasional "hey, tomas, go RTFM now" --
> although I try, as well as I can, to not inflict that on people.

People need specific references and despite provision in Emacs it is
not always obvious. There is Help menu -> Search Documentation and
many different queries are there. Even thought search functions are
available they may not be as obvious.

It is with many software like that.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Monday, November 30, 2020 at 11:41 AM
> From: tomas@tuxteam.de
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> On Mon, Nov 30, 2020 at 11:09:52AM +0100, Christopher Dimech wrote:
>
> [...]
>
> > Correct.  Still I am working on that and have included it in formal work.
> > If Gnu work continues to be simply a spare time thing many problems will
> > arise as we are witnessing.
>
> I don't know, really. Having seen "paid-for" manuals before, I'd dare
> to say that I am spoilt, as an almost-exclusive free software user.

I do not know how many have experience in writing and dealing with
editors, and get published in say National Geographic (paid-for) -
or Playboy for that matter. Criticism can be very hard and authors
have to deal with that.  Much worse than criticisms one gets about
a manual.

Am not saying editors are always right.  And I know of instances where
author find support from other editors, even though their peers and
reviewers advocate against it.  I used to get very upset and
disheartened when I first started sending articles to magazines.
It took a few years before an editor contacted me for a deal.

> And having been stranded in more than one support hell, superficially
> friendly (but you know it's a template, peppered with "user experience"
> and things), but they let you know that all is about reducing per-issue
> cost (and you /are/ an issue)...

Yes, mailing lists loads do get overwhelming.  There's no argument about
that.  However, being aware of what is happening within the larger Gnu
Framework does inform.

> ...I seriously prefer the occasional "hey, tomas, go RTFM now" --
> although I try, as well as I can, to not inflict that on people.

Am not against people saying that, but authors have to swallow
their pride if they want to write well.

This simply follows your discussion on the topic without criticisms
being addressed to you personally.  These few days we saw some serious
infrastructural problems cropping up, but after some quite painful
discussion we helped them.  It is always helpful ta assume that other
persons could know something we don't.

Cheers

> Cheers
>  - t
>

RE: Auto Fill Comments

[Drew Adams]

> Like my mother, she was in Paris 1968 and there was a campaign in
> the subway: "One liter of wine a day is enough"

Sous les pavés, la plage !

Re: Auto Fill Comments

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> Like my mother, she was in Paris 1968 and there was a campaign
>> in the subway: "One liter of wine a day is enough"
>
> Sous les pavés, la plage !

Yes... there was that as well.

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

Re: Auto Fill Comments

[Andreas Eder]

On So 29 Nov 2020 at 18:38, Drew Adams <drew.adams@oracle.com> wrote:

>> Like my mother, she was in Paris 1968 and there was a campaign in
>> the subway: "One liter of wine a day is enough"
>
> Sous les pavés, la plage !

+1

Here, it was the local version: Unter dem Pflaster der Strand.
There even was a magazine withe the name PflasterStrand!

'Andreas

Re: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-11-30 03:08]:
> The problem starts with actually trying to do something after deciding to
> give elisp a try.  Very often this requires a lot of emacs specific knowledge.
> There need to be links with very clear steps.  If you want X, here's how you
> do it, geared towards the beginning developer (to elisp, not to development).
> For the expert, there are all lots or resources to find information.

The EmacsWiki.org
https://www.emacswiki.org/

EmacsWiki could be good place for that. But one can see that people
access various other communities such as Reddit and Stackexchange to
get answers to their questions.

What could help is the centralized dynamic knowledge repository that
users could consult and browse to quickly find various pieces of
information

EmacsWiki is one such repository. But then we have mailing lists. Then
we have Reddit an Stackexchange, and plethora of various other
websites. Search engines sometimes help, sometimes not. To me search
engines help less than mailing lists.

Locating proper information is problem. It requires cataloging entries
into their categories, tagging them, and so on.

Re: Auto Fill Comments

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> Thanks Michael.  I will have a go at it this week.

I now have read the according pages in the manual,

  (info "(elisp) Buffer-Local Variables")

A bit more wordy and complete than the short summary I gave, but still
pleasantly readable, in my opinion.  Since you criticized the manual,
you must allow these questions:

Had you found and read that?  Or did you fail finding because you
searched for the (wrong) term "local variables" and gave up because you
felt lost?  Something else?

Thanks,

Michael.

Re: Auto Fill Comments

[Christopher Dimech]

I understand that local variables are meant for buffer customization that
one uses most often in mode hooks.  There has been some misunderstanding.

By not very good I meant: Can we have a typical example and how it would look like.
I mean, rather than with foo, bar, a, g, temp, body.  For instance, making a command
for some particular mode buffer, and a brief description of what is achieved.  Apologies
should I not understand how hard that can be.  Hope my comment helps transmit what I mean
better.

Regards
Christopher

> Sent: Monday, November 30, 2020 at 10:19 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Thanks Michael.  I will have a go at it this week.
>
> I now have read the according pages in the manual,
>
>   (info "(elisp) Buffer-Local Variables")
>
> A bit more wordy and complete than the short summary I gave, but still
> pleasantly readable, in my opinion.  Since you criticized the manual,
> you must allow these questions:
>
> Had you found and read that?  Or did you fail finding because you
> searched for the (wrong) term "local variables" and gave up because you
> felt lost?  Something else?
>
> Thanks,
>
> Michael.
>
>
>

Re: Auto Fill Comments

[tomas]

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

On Mon, Nov 30, 2020 at 11:14:59PM +0100, Christopher Dimech wrote:
> I understand that local variables are meant for buffer customization that
                    ^^^^^
> one uses most often in mode hooks.  There has been some misunderstanding.

You surely  mean... "buffer-local" up there.

> By not very good I meant: Can we have a typical example and how it would look like.
> I mean, rather than with foo, bar, a, g, temp, body.  For instance, making a command
> for some particular mode buffer, and a brief description of what is achieved.  Apologies
> should I not understand how hard that can be.  Hope my comment helps transmit what I mean
> better.

I just have a typical example in front of me right now. I have a small
program written in Scheme. To make sure Emacs starts Scheme mode, the
end of the file has:

;; Local Variables:
;; mode: scheme
;; End:

This makes sure the variable `mode' is set to the value "scheme". But
this has to happen buffer-locally, so only the buffer visiting that
file is set to scheme major mode. Would that happen to all buffers,
I might end up pretty confused.

Does that make sense?

Cheers
 - t

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

Re: Auto Fill Comments

[Stefan Monnier]

> I just have a typical example in front of me right now. I have a small
> program written in Scheme. To make sure Emacs starts Scheme mode, the
> end of the file has:
>
> ;; Local Variables:
> ;; mode: scheme
> ;; End:
>
> This makes sure the variable `mode' is set to the value "scheme". But

Hmm... not sure if it's the best example: there is no `mode` variable.
The corresponding variable is called `major-mode` and will be set to
`scheme-mode` and the above doesn't set the var directly but just calls
the function `scheme-mode` (which then sets the var, tho it doesn't
have to: you can also use `;; mode: auto-fill` which will enable
`auto-fill-mode` and won't set `major-mode`).

IOW, in file-local variables, `mode` is quite special (there aren't many
such exceptions.  The main other one is `coding`).

        Stefan

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Monday, November 30, 2020 at 11:32 PM
> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> > I just have a typical example in front of me right now. I have a small
> > program written in Scheme. To make sure Emacs starts Scheme mode, the
> > end of the file has:
> >
> > ;; Local Variables:
> > ;; mode: scheme
> > ;; End:
> >
> > This makes sure the variable `mode' is set to the value "scheme". But
>
> Hmm... not sure if it's the best example: there is no `mode` variable.
> The corresponding variable is called `major-mode` and will be set to
> `scheme-mode` and the above doesn't set the var directly but just calls
> the function `scheme-mode` (which then sets the var, tho it doesn't
> have to: you can also use `;; mode: auto-fill` which will enable
> `auto-fill-mode` and won't set `major-mode`).
>
> IOW, in file-local variables, `mode` is quite special (there aren't many
> such exceptions.  The main other one is `coding`).
>
>         Stefan
>

I agree with Stefan's evaluation.  It must be specifically elisp coding
and coding many would try to do os have set when working on their own
files (perhaps they have been coding in c, for instance).

Re: Auto Fill Comments

[tomas]

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

On Mon, Nov 30, 2020 at 05:32:55PM -0500, Stefan Monnier wrote:
> > I just have a typical example in front of me right now. I have a small
> > program written in Scheme. To make sure Emacs starts Scheme mode, the
> > end of the file has:
> >
> > ;; Local Variables:
> > ;; mode: scheme
> > ;; End:
> >
> > This makes sure the variable `mode' is set to the value "scheme". But
> 
> Hmm... not sure if it's the best example: there is no `mode` variable.

Whooops :-)

embarrasing.

OK, ok. Merging with the other subthread, just imagine I had
there

;; Local Variables
;; fill-width: 64
;; End:

Cheers
 - t

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

RE: Auto Fill Comments

[Drew Adams]

> I understand that local variables are meant for buffer customization
> that
> one uses most often in mode hooks.  There has been some
> misunderstanding.
> 
> By not very good I meant: Can we have a typical example and how it
> would look like.
> I mean, rather than with foo, bar, a, g, temp, body.  For instance,
> making a command
> for some particular mode buffer, and a brief description of what is
> achieved.  Apologies
> should I not understand how hard that can be.  Hope my comment helps
> transmit what I mean
> better.

It doesn't get any more specific than this, IMO:

`C-x f' aka `M-x set-fill-column'.

Tada!  Variable `fill-column' just got its value
updated for the current buffer.

`C-h f' tells you that that command sets var
`fill-column'.

Clicking that var name in *Help* then tells you
that the var:

   Automatically becomes buffer-local when set.
   ^^^^^^^^^^^^^

That is, this particular variable is ALWAYS 
buffer-local - its value is separate for each
buffer.

What does "automatically" mean here?  It means
that to make it buffer-local you don't need to
do anything - you have no choice: it's
buffer-local in every buffer.

Why would that be the case for `fill-column'?
Because we figure it makes sense to always give
it a buffer-local value, that's all.

You can set the _default_ value for all buffers
using Customize (as the doc string tells you).

E.g., customize `fill-column' to 71, and if
nothing sets it to something different in a
given buffer then it'll be 71.

Most variables that might have buffer-local
values in some buffers do NOT automatically
become buffer-local in every buffer.  That is,
they are not "automatically" buffer-local.

They become buffer-local for a given buffer
only if something explicitly makes them
buffer-local there, e.g., using function
`make-local-variable'.

To make a variable ALWAYS (i.e.,
"automatically") be buffer-local (i.e., in
all buffers) you use the stronger function
`make-variable-buffer-local'.  The doc strings
(`C-h f') of those two functions tell you all
of this.

(`make-local-variable' might be more precisely
named `give-var-a-separate-value-in-THIS-buffer'.)

And yes (sigh), I'm just repeating what the
help and doc say better.  RTFM really is your
friend, you know. ;-)

Re: RE: Auto Fill Comments

[Christopher Dimech]

That's a great example.  We can have a function that sets fill-column
as buffer-local and hook it to programming mode, c-mode say.  That would
be a useful example.  And users can try it out and see things work.

Yes, it is repeating and RTFM, but with a serious code example to excite
people to write actual code after the prose.

Thank you so very much.
Christopher


> Sent: Monday, November 30, 2020 at 11:45 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>, "Michael Heerdegen" <michael_heerdegen@web.de>
> Cc: help-gnu-emacs@gnu.org
> Subject: RE: Auto Fill Comments
>
> > I understand that local variables are meant for buffer customization
> > that
> > one uses most often in mode hooks.  There has been some
> > misunderstanding.
> >
> > By not very good I meant: Can we have a typical example and how it
> > would look like.
> > I mean, rather than with foo, bar, a, g, temp, body.  For instance,
> > making a command
> > for some particular mode buffer, and a brief description of what is
> > achieved.  Apologies
> > should I not understand how hard that can be.  Hope my comment helps
> > transmit what I mean
> > better.
>
> It doesn't get any more specific than this, IMO:
>
> `C-x f' aka `M-x set-fill-column'.
>
> Tada!  Variable `fill-column' just got its value
> updated for the current buffer.
>
> `C-h f' tells you that that command sets var
> `fill-column'.
>
> Clicking that var name in *Help* then tells you
> that the var:
>
>    Automatically becomes buffer-local when set.
>    ^^^^^^^^^^^^^
>
> That is, this particular variable is ALWAYS
> buffer-local - its value is separate for each
> buffer.
>
> What does "automatically" mean here?  It means
> that to make it buffer-local you don't need to
> do anything - you have no choice: it's
> buffer-local in every buffer.
>
> Why would that be the case for `fill-column'?
> Because we figure it makes sense to always give
> it a buffer-local value, that's all.
>
> You can set the _default_ value for all buffers
> using Customize (as the doc string tells you).
>
> E.g., customize `fill-column' to 71, and if
> nothing sets it to something different in a
> given buffer then it'll be 71.
>
> Most variables that might have buffer-local
> values in some buffers do NOT automatically
> become buffer-local in every buffer.  That is,
> they are not "automatically" buffer-local.
>
> They become buffer-local for a given buffer
> only if something explicitly makes them
> buffer-local there, e.g., using function
> `make-local-variable'.
>
> To make a variable ALWAYS (i.e.,
> "automatically") be buffer-local (i.e., in
> all buffers) you use the stronger function
> `make-variable-buffer-local'.  The doc strings
> (`C-h f') of those two functions tell you all
> of this.
>
> (`make-local-variable' might be more precisely
> named `give-var-a-separate-value-in-THIS-buffer'.)
>
> And yes (sigh), I'm just repeating what the
> help and doc say better.  RTFM really is your
> friend, you know. ;-)
>

Re: RE: Auto Fill Comments

[tomas]

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

On Tue, Dec 01, 2020 at 12:22:11AM +0100, Christopher Dimech wrote:
> That's a great example.  We can have a function that sets fill-column
> as buffer-local and hook it to programming mode, c-mode say.

Why mix a mode in? This makes the example unnecessarily complex.
Just fill-column, buffer-local, that's it.

>                                                     That would
> be a useful example.  And users can try it out and see things work.
> 
> Yes, it is repeating and RTFM, but with a serious code example to excite
> people to write actual code after the prose.

The interesting challenge is that different people have diverse
approaches at learning. Covering as much ground as possible
without exploding in size (which would hinder learning, too)
is that Herculean task. That's probably why there's more than
1 book.

I claim the Emacs folks have done an outstanding job with the
two manuals and the introduction /on top of/ the whole "live"
doc (docstrings, ref to source, etc.). The only software projects
I could name rivalling that doc would be Don Knuth's TeX and
METAFONT, but they are (one? several?) orders of magnitude less
complex than Emacs at this point.

Cheers
 - t

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

Re: RE: Auto Fill Comments

[Christopher Dimech]

> Sent: Tuesday, December 01, 2020 at 9:42 AM
> From: tomas@tuxteam.de
> To: help-gnu-emacs@gnu.org
> Subject: Re: RE: Auto Fill Comments
>
> On Tue, Dec 01, 2020 at 12:22:11AM +0100, Christopher Dimech wrote:
> > That's a great example.  We can have a function that sets fill-column
> > as buffer-local and hook it to programming mode, c-mode say.
>
> Why mix a mode in? This makes the example unnecessarily complex.
> Just fill-column, buffer-local, that's it.
>
> >                                                     That would
> > be a useful example.  And users can try it out and see things work.
> >
> > Yes, it is repeating and RTFM, but with a serious code example to excite
> > people to write actual code after the prose.
>
> The interesting challenge is that different people have diverse
> approaches at learning. Covering as much ground as possible
> without exploding in size (which would hinder learning, too)
> is that Herculean task. That's probably why there's more than
> 1 book.

Have thought about that.  Perhaps we can leave the current manual
alone as an advanced reference.  How do others feel about it?

It is good that the challenge is being recognised.  I can see
what I can do from my side. I understand your concern and shall
focus on an abbreviated guide.

> I claim the Emacs folks have done an outstanding job with the
> two manuals and the introduction /on top of/ the whole "live"
> doc (docstrings, ref to source, etc.). The only software projects
> I could name rivalling that doc would be Don Knuth's TeX and
> METAFONT, but they are (one? several?) orders of magnitude less
> complex than Emacs at this point.
>
> Cheers
>  - t
>

Re: RE: Auto Fill Comments

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2020-12-01 18:51]:
> Have thought about that.  Perhaps we can leave the current manual
> alone as an advanced reference.  How do others feel about it?

There is:

1. Tutorial

2. Emacs Reference, and

3. Emacs Manual

If you have good writing skills then I suggest to first make something
like a speedy introduction, easier than Tutorial. Then let us read
here, criticize it, or suggest improvements.

Then you could make something between Tutorial and Emacs Manual.

Re: RE: Auto Fill Comments

[Christopher Dimech]

> Sent: Tuesday, December 01, 2020 at 5:35 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: RE: Auto Fill Comments
>
> * Christopher Dimech <dimech@gmx.com> [2020-12-01 18:51]:
> > Have thought about that.  Perhaps we can leave the current manual
> > alone as an advanced reference.  How do others feel about it?
>
> There is:
>
> 1. Tutorial
>
> 2. Emacs Reference, and
>
> 3. Emacs Manual
>
> If you have good writing skills then I suggest to first make something
> like a speedy introduction, easier than Tutorial. Then let us read
> here, criticize it, or suggest improvements.
>
> Then you could make something between Tutorial and Emacs Manual.
>

Fair enough.  Deal then.

Cheers
C*

Re: Auto Fill Comments

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> > Then you could make something between Tutorial and Emacs Manual.
>
> Fair enough.  Deal then.

I have thought we could have something in the form of an FAQ list, with
questions often asked here.  It could offer references to the manuals we
have, but it would not have the form of a manual, it would just be a
collection of entry points coming from typical tasks a user is
confronted with.  That would also make it easy to write and maintain.

And I think, not only would it be good if maintainers (Eli, in
particular) would be completely out, it would even be best if it would
be completely created by normal users, with a bit of review help by the
experts.

Michael. 

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Tuesday, December 01, 2020 at 8:33 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > > Then you could make something between Tutorial and Emacs Manual.
> >
> > Fair enough.  Deal then.
>
> I have thought we could have something in the form of an FAQ list, with
> questions often asked here.  It could offer references to the manuals we
> have, but it would not have the form of a manual, it would just be a
> collection of entry points coming from typical tasks a user is
> confronted with.  That would also make it easy to write and maintain.

> And I think, not only would it be good if maintainers (Eli, in
> particular) would be completely out, it would even be best if it would
> be completely created by normal users, with a bit of review help by the
> experts.

Thank you for the positive constructive criticism so we can make this happen.
Please, let's stop "experts" to define yourselves as I am really fed up of all
this hyperbole.

This is an old discussion.  You may look the other side or face the problem
once and for all.

> Michael.
>
>
>

Re: Auto Fill Comments

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> Thank you for the positive constructive criticism so we can make this
> happen.

Hoping that was not irony, but I'm not sure.

> Please, let's stop "experts" to define yourselves as I am really fed
> up of all this hyperbole.

What alternative wording would you suggest?  We will need to describe
with words who and who not we want to work on the new material.

Regards,

Michael

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Tuesday, December 01, 2020 at 10:42 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Thank you for the positive constructive criticism so we can make this
> > happen.
>
> Hoping that was not irony, but I'm not sure.

Absolutely not irony.

> > Please, let's stop "experts" to define yourselves as I am really fed
> > up of all this hyperbole.
>
> What alternative wording would you suggest?  We will need to describe
> with words who and who not we want to work on the new material.

it would even be best if it would be completely created by normal users,
the result of which we can then review.  "We" can also be changed to
"Emacs Documentation Delegates" or the like.  Although you can use
"experts" if used sparingly.  It is customary that "expert" is
not used to describe oneself, but to describe someone else.  It is
particularly used in introductions or to cite specific work considered
outstanding.

Be assured I am not against hierarchy.  Coordination would be required indeed.
Lately my biggest contribution has been in texinfo, with no plans to take over
emacs or its documentation.  But simply because many users are keen to do some
customisations without having to ask other users to help them immediately.

The positive thing would be that users would likely come up with some decent
code structures which the emacs community can then help them polish if need be.

PS: It is not necessary to rewrite things so as not to use experts.  Am not
that fidgety or sensitive.  And you do help.  So it's ok.

Sincerely
Christopher

> Regards,
>
> Michael
>
>
>

Re: Auto Fill Comments

[Christopher Dimech]

To help with the discussion, read this message from Richard.  Properly working
examples are very important.

Re: The poor state of documentation of pcase like things.
From: 	Richard Stallman
Subject: 	Re: The poor state of documentation of pcase like things.
Date: 	Mon, 21 Dec 2015 00:04:21 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

> It matches anything (like a variable) but does not actually bind a variable.

Alas, that's the half of the answer that I already knew.
What I don't know is, how do you _write_ the use of _?
That seemed self-contradictory in the text that was posted.

Can someone show me some properly working examples of _ in pcase
and say what they do?

--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.






> Sent: Tuesday, December 01, 2020 at 8:33 PM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > > Then you could make something between Tutorial and Emacs Manual.
> >
> > Fair enough.  Deal then.
>
> I have thought we could have something in the form of an FAQ list, with
> questions often asked here.  It could offer references to the manuals we
> have, but it would not have the form of a manual, it would just be a
> collection of entry points coming from typical tasks a user is
> confronted with.  That would also make it easy to write and maintain.
>
> And I think, not only would it be good if maintainers (Eli, in
> particular) would be completely out, it would even be best if it would
> be completely created by normal users, with a bit of review help by the
> experts.
>
> Michael.
>
>
>

Re: Auto Fill Comments

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> Can someone show me some properly working examples of _ in pcase
> and say what they do?

A simple example?

#+begin_src emacs-lisp
(pcase person
  ('christopher (message "Hello, Christopher!"))
  ('michael) ; do nothing and return nil
  ;; catchall branch:
  (_            (message "Hello, how are you?")))
#+end_src

Of course one can use it, like any other pattern, to assemble compounded
patterns.  It is particularly useful in backquote patterns for example.

IME the `pcase' occurrences in the Emacs sources offer a nice set of
examples, once one has got an idea of the concept.

Michael.

Re: Auto Fill Comments

[Christopher Dimech]

It is a motivation of how beneficial properly working examples
would be, to have in manuals, if they are not too long.

Naturally, it is up to author discretion, but good to keep in mind.

> Sent: Wednesday, December 02, 2020 at 12:16 AM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Can someone show me some properly working examples of _ in pcase
> > and say what they do?
>
> A simple example?
>
> #+begin_src emacs-lisp
> (pcase person
>   ('christopher (message "Hello, Christopher!"))
>   ('michael) ; do nothing and return nil
>   ;; catchall branch:
>   (_            (message "Hello, how are you?")))
> #+end_src
>
> Of course one can use it, like any other pattern, to assemble compounded
> patterns.  It is particularly useful in backquote patterns for example.
>
> IME the `pcase' occurrences in the Emacs sources offer a nice set of
> examples, once one has got an idea of the concept.
>
> Michael.
>
>

Re: Auto Fill Comments

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2020-12-01 22:38]:
> Christopher Dimech <dimech@gmx.com> writes:
> 
> > > Then you could make something between Tutorial and Emacs Manual.
> >
> > Fair enough.  Deal then.
> 
> I have thought we could have something in the form of an FAQ list, with
> questions often asked here.  It could offer references to the manuals we
> have, but it would not have the form of a manual, it would just be a
> collection of entry points coming from typical tasks a user is
> confronted with.  That would also make it easy to write and
> maintain.

Something like self-hosted question and answer:
https://askbot.com/

Re: RE: Auto Fill Comments

[Christopher Dimech]

> Sent: Tuesday, December 01, 2020 at 9:42 AM
> From: tomas@tuxteam.de
> To: help-gnu-emacs@gnu.org
> Subject: Re: RE: Auto Fill Comments
>
> On Tue, Dec 01, 2020 at 12:22:11AM +0100, Christopher Dimech wrote:
> > That's a great example.  We can have a function that sets fill-column
> > as buffer-local and hook it to programming mode, c-mode say.
>
> Why mix a mode in? This makes the example unnecessarily complex.
> Just fill-column, buffer-local, that's it.

Because we should not kid users by showing an example that we already
know is buffer local, and don't have to do anything.  Still, perhaps
doing that on the reference creates more problems than solves.

> >                                                     That would
> > be a useful example.  And users can try it out and see things work.
> >
> > Yes, it is repeating and RTFM, but with a serious code example to excite
> > people to write actual code after the prose.
>
> The interesting challenge is that different people have diverse
> approaches at learning. Covering as much ground as possible
> without exploding in size (which would hinder learning, too)
> is that Herculean task. That's probably why there's more than
> 1 book.
>
> I claim the Emacs folks have done an outstanding job with the
> two manuals and the introduction /on top of/ the whole "live"
> doc (docstrings, ref to source, etc.). The only software projects
> I could name rivalling that doc would be Don Knuth's TeX and
> METAFONT, but they are (one? several?) orders of magnitude less
> complex than Emacs at this point.
>
> Cheers
>  - t
>

Re: Auto Fill Comments

[Michael Heerdegen]

Christopher Dimech <dimech@gmx.com> writes:

> I mean, rather than with foo, bar, a, g, temp, body.

I see.  This example demonstrates subtle parts of the semantics instead
of mentioning a typical use case.

Could be as simple as: "for example, to set the binding of `fill-column'
only for the current buffer, do it like (setq-local fill-column 70)" as
an preliminary example.

I see there is a certain gap between the user manual, which doesn't
cover this concept, and the Elisp manual, which is very detailed if a
user doesn't want to write a package but just needs some basics to be
able to make his config a bit more mode aware.

But I guess it is a task not as simply as it seems: we need to know what
the typical use case for user's customizations is, when a typical use
case exists at all.  And we still need the academicly abstract examples
to teach people the other important aspects.


Regards,

Michael.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Tuesday, December 01, 2020 at 12:12 AM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > I mean, rather than with foo, bar, a, g, temp, body.
>
> I see.  This example demonstrates subtle parts of the semantics instead
> of mentioning a typical use case.
>
> Could be as simple as: "for example, to set the binding of `fill-column'
> only for the current buffer, do it like (setq-local fill-column 70)" as
> an preliminary example.
>
> I see there is a certain gap between the user manual, which doesn't
> cover this concept, and the Elisp manual, which is very detailed if a
> user doesn't want to write a package but just needs some basics to be
> able to make his config a bit more mode aware.

Spot on.  For those who get excited and take the challenge to try customising
emacs, but are not skillful enough to be emacs package developers.  It
does not even have to be in the reference manual.  It could be an intermediate
guide between introduction and full reference.

> But I guess it is a task not as simply as it seems: we need to know what
> the typical use case for user's customizations is, when a typical use
> case exists at all.  And we still need the academicly abstract examples
> to teach people the other important aspects.

Certainly not easy.  Yes, one needs to know typical use cases that users
would like to customise themselves.  I mean, not "customise themselves",
but ... customise emacs themselves :)


>
> Regards,
>
> Michael.
>
>
>

Re: Auto Fill Comments

[Yuri Khan]

On Sun, 29 Nov 2020 at 09:24, Christopher Dimech <dimech@gmx.com> wrote:

> Message understood.  Let's go back do some work and perhaps next year I'll
> solve it and tell you all about it.  But I wonder how many people would use
> to.  Is it really a waste of time?

Autofilling really is a waste of time these days.
It was useful during the days
you’d write in plain text,
keep multiple dated backups,
and then print it out as-is.
But these days we have Markdown processors / Org export,
automatic layout,
and version control systems.
It is a good idea
to stop worrying about filling the line width to a certain column
and structure text so as to minimize diff churn when you rewrite something.

https://rhodesmill.org/brandon/2012/one-sentence-per-line/

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Sunday, November 29, 2020 at 8:52 AM
> From: "Yuri Khan" <yuri.v.khan@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Michael Heerdegen" <michael_heerdegen@web.de>, "help-gnu-emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Auto Fill Comments
>
> On Sun, 29 Nov 2020 at 09:24, Christopher Dimech <dimech@gmx.com> wrote:
> 
> > Message understood.  Let's go back do some work and perhaps next year I'll
> > solve it and tell you all about it.  But I wonder how many people would use
> > to.  Is it really a waste of time?
> 
> Autofilling really is a waste of time these days.
> It was useful during the days
> you’d write in plain text,
> keep multiple dated backups,
> and then print it out as-is.
> But these days we have Markdown processors / Org export,
> automatic layout,
> and version control systems.
> It is a good idea
> to stop worrying about filling the line width to a certain column
> and structure text so as to minimize diff churn when you rewrite something.
> 
> https://rhodesmill.org/brandon/2012/one-sentence-per-line/
 
I see.  Many thanks.

Re: Auto Fill Comments

[Christopher Dimech]

Always listening to positive applause is not a good strategy.
Had superiors like that.  Terrible.


> Sent: Saturday, November 28, 2020 at 8:46 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Date: Fri, 27 Nov 2020 23:15:58 +0100
> >
> > And if you ask for help everybody is suddenly quiet.  I would be pissed
> > off.  I don't know where Eli's motivation comes from.
>
> My motivation comes from the urge to keep improving the Emacs
> documentation.  I cannot possibly do that with "criticism" that just
> says our documentation sucks and should be rewritten, because that's
> not useful: I don't know how to convert that to any useful list of
> things to fix.
>
> And, of course, saying that the manuals should be rewritten is a clear
> sign that the person probably doesn't know how to use the Info mode
> efficiently, and probably didn't read too much of said documentation.
> Which further diminishes the useful payload of such claims.
>
>

Re: Auto Fill Comments

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Fri, 27 Nov 2020 22:26:13 +0100
> Cc: help-gnu-emacs@gnu.org
> 
> > Documentation, however, is to be structured according to different levels
> > of sophistication.  But I understand it could be a lot of work to complete.
> > Was not my intention to deride anyone. but to describe how it is.  Documentation
> > is always better than no documentation.  And everyone does as one can.
> 
> True. However, Emacs manuals are written by volunteers with limited
> resources in their spair time (I hack Emacs as a hobby when I drink
> coffee), so what is practical has also to be take into account. They
> have to prioritize what level they put themselves on, especially Elisp
> manual.

That is true, but please point me to a Free Software project that has
better documentation than Emacs, let alone documentation better
structured according to different levels of sophistication.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Saturday, November 28, 2020 at 8:33 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> > From: Arthur Miller <arthur.miller@live.com>
> > Date: Fri, 27 Nov 2020 22:26:13 +0100
> > Cc: help-gnu-emacs@gnu.org
> >
> > > Documentation, however, is to be structured according to different levels
> > > of sophistication.  But I understand it could be a lot of work to complete.
> > > Was not my intention to deride anyone. but to describe how it is.  Documentation
> > > is always better than no documentation.  And everyone does as one can.
> >
> > True. However, Emacs manuals are written by volunteers with limited
> > resources in their spair time (I hack Emacs as a hobby when I drink
> > coffee), so what is practical has also to be take into account. They
> > have to prioritize what level they put themselves on, especially Elisp
> > manual.
>
> That is true, but please point me to a Free Software project that has
> better documentation than Emacs, let alone documentation better
> structured according to different levels of sophistication.

I agree that it is a mainly an optimisation scheme for working on a
complex structure rather than a PR Exercise Among Packages.

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Saturday, November 28, 2020 at 8:33 AM
>> From: "Eli Zaretskii" <eliz@gnu.org>
>> To: help-gnu-emacs@gnu.org
>> Subject: Re: Auto Fill Comments
>>
>> > From: Arthur Miller <arthur.miller@live.com>
>> > Date: Fri, 27 Nov 2020 22:26:13 +0100
>> > Cc: help-gnu-emacs@gnu.org
>> >
>> > > Documentation, however, is to be structured according to different levels
>> > > of sophistication.  But I understand it could be a lot of work to complete.
>> > > Was not my intention to deride anyone. but to describe how it is.  Documentation
>> > > is always better than no documentation.  And everyone does as one can.
>> >
>> > True. However, Emacs manuals are written by volunteers with limited
>> > resources in their spair time (I hack Emacs as a hobby when I drink
>> > coffee), so what is practical has also to be take into account. They
>> > have to prioritize what level they put themselves on, especially Elisp
>> > manual.
>>
>> That is true, but please point me to a Free Software project that has
>> better documentation than Emacs, let alone documentation better
>> structured according to different levels of sophistication.
I certainly can't. Emacs has definitely best docs nowadays; I can't say
nothing about levels of sphistication, since I am not well sophisticated
by my nature :-), but Emacs is definitely very well documented.

I use mostly C-h f so I can drop into docs, and if I don't understand
docs, I look at the source code; with Helpful package I am in C-code in
no time, usually. Helm is good for discovering; I can just type a letter
or few and see what it brings me for more exploration.

RE: Auto Fill Comments

[Drew Adams]

> My experience has been that as I got to do more things in emacs lisp,
> the understanding needed quickly exceeded my rate of learning.

I'd put it this way, speaking of myself and others I know:

 "the understanding possible quickly exceeded..."

IOW, as usual in life, the more you know the more
questions you have - and the more interesting the
questions are.

It's not so much that I _need_ to know all the
stuff I've newly become aware of.  It's that I
_can_ learn it.  And yes, sometimes it's not
immediately obvious which of all the new info
I glimpse on the horizon I really do need
immediately.

> One can get to sophisticated constructs, even when trying to do
> relatively simple things.  You never know where your original
> plan could get you. Many times the importance of a work is not
> measured by its consequences (i.e. by the final command).

100% agreement.

But again, this is not a failing from the fact
that all that additional info is _available_.

It can be a failing if you can't see how you
really want (or need) to proceed, to get to the
info you most immediately need.

Re: RE: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 8:06 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>, tomas@tuxteam.de
> Cc: help-gnu-emacs@gnu.org
> Subject: RE: Auto Fill Comments
>
> > My experience has been that as I got to do more things in emacs lisp,
> > the understanding needed quickly exceeded my rate of learning.
>
> I'd put it this way, speaking of myself and others I know:
>
>  "the understanding possible quickly exceeded..."
>
> IOW, as usual in life, the more you know the more
> questions you have - and the more interesting the
> questions are.
>
> It's not so much that I _need_ to know all the
> stuff I've newly become aware of.  It's that I
> _can_ learn it.  And yes, sometimes it's not
> immediately obvious which of all the new info
> I glimpse on the horizon I really do need
> immediately.
>
> > One can get to sophisticated constructs, even when trying to do
> > relatively simple things.  You never know where your original
> > plan could get you. Many times the importance of a work is not
> > measured by its consequences (i.e. by the final command).
>
> 100% agreement.
>
> But again, this is not a failing from the fact
> that all that additional info is _available_.

Agreed, at times it is about discovery and re-discovery.

> It can be a failing if you can't see how you
> really want (or need) to proceed, to get to the
> info you most immediately need.
>
>

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Friday, November 27, 2020 at 9:51 AM
>> From: "Arthur Miller" <arthur.miller@live.com>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: help-gnu-emacs@gnu.org
>> Subject: Re: Auto Fill Comments
>>
>> Christopher Dimech <dimech@gmx.com> writes:
>>
>> >> Sent: Friday, November 27, 2020 at 8:28 AM
>> >> From: "Eli Zaretskii" <eliz@gnu.org>
>> >> To: help-gnu-emacs@gnu.org
>> >> Subject: Re: Auto Fill Comments
>> >>
>> >> > From: Christopher Dimech <dimech@gmx.com>
>> >> > Date: Fri, 27 Nov 2020 01:47:08 +0100
>> >> > Sensitivity: Normal
>> >> > Cc: help-gnu-emacs@gnu.org
>> >> >
>> >> > The manuals should be rewritten because they are incomprehensible.
>> >> > Perhaps it was good in the eighties.  It continues forever.  Consider
>> >> > "face customisation" for instance, which just means font.  Nobody
>> >> > fuckin reads a manual with 17 nodes.  You don't know which one to use,
>> >> > which commands are most useful, and so on.  The problem gets compounded
>> >> > because every esoteric command is there.
>> >> >
>> >> > You are just insisting on something bad and inefficient.
>> >>
>> >> Fair warning: if that is your attitude towards our documentation,
>> >> please be aware that there will be some people here who'd refrain from
>> >> helping you.  We don't work for you, so if you refuse to help yourself
>> >> by becoming more proficient with the extensive documentation features
>> >> in Emacs, we cannot be expected to hold your hand forever.
>> >
>> > It is well known that some at Gnu cannot take criticisms when others
>> > try to read what others write.  I am a writer by profession.  So spare
>> > me the "Don't work for you" defensive approach.
>> I already hinted you that you could hire a professional writer to clean
>> the swamp for you. Why do you think I told you that? :D
>>
>> Nobody here works for you. Not Eli, nor everybody else.
>>
>> Believe me, Emacs documentation is not the problem. You maybe are
>> writer, but you are certainly not a programmer; otherwise you wouldn't
>> ask how to start a Java application :-). We all have strengths and
>> weaknesses; your strength is obviously not programming. Nothing shame in
>> that, not everybody has to be a programmer.
>
> The programming craft is in the source code.  The documentation is to help
> understand it.  Could be even harder than writing the code.  It makes a
> convenient listing if you know what you're doing.  It's not always the failure
> of readers.
Of course it is not always the failure of readers, I did not say it
either.

Re: Auto Fill Comments

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-11-27 11:52]:
> I already hinted you that you could hire a professional writer to clean
> the swamp for you. Why do you think I told you that? :D
> 
> Nobody here works for you. Not Eli, nor everybody else.
> 
> Believe me, Emacs documentation is not the problem. You maybe are
> writer, but you are certainly not a programmer; otherwise you wouldn't
> ask how to start a Java application :-). We all have strengths and
> weaknesses; your strength is obviously not programming. Nothing shame in
> that, not everybody has to be a programmer.

Why not, people learn languages and there are programmers coming from
other language, switching languages, they know in one language
majority of things and not in the new language.

In general, there is nothing wrong in asking. It is better that we
give incentives here to ask any questions by anybody regardless if
programmers or not programmers.

If any person is configuring ~/.emacs or init.el then they are
becoming programmers it is progress and is good encouraging progress.

How many programming languages there are? I hope that definition of
programmer will not change through time that it requires multiple
programming languages or being paid for the work. Many children today
are programmers, I would not call them not programmer if they do not
know Java but they know how to instruct Lego robot.

Re: Auto Fill Comments

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-11-27 11:52]:
>> I already hinted you that you could hire a professional writer to clean
>> the swamp for you. Why do you think I told you that? :D
>> 
>> Nobody here works for you. Not Eli, nor everybody else.
>> 
>> Believe me, Emacs documentation is not the problem. You maybe are
>> writer, but you are certainly not a programmer; otherwise you wouldn't
>> ask how to start a Java application :-). We all have strengths and
>> weaknesses; your strength is obviously not programming. Nothing shame in
>> that, not everybody has to be a programmer.
>
> Why not, people learn languages and there are programmers coming from
> other language, switching languages, they know in one language
> majority of things and not in the new language.
>
> In general, there is nothing wrong in asking. It is better that we
> give incentives here to ask any questions by anybody regardless if
> programmers or not programmers.
>
> If any person is configuring ~/.emacs or init.el then they are
> becoming programmers it is progress and is good encouraging progress.
>
> How many programming languages there are? I hope that definition of
> programmer will not change through time that it requires multiple
> programming languages or being paid for the work. Many children today
> are programmers, I would not call them not programmer if they do not
> know Java but they know how to instruct Lego robot.
Yeah sure; I agree; I just answered him myself; I did not mean
always. It is not always problem in user; manual can be written badly
too, or lacking information etc. I ask myself sometimes. By being a
programmer I don't mean by having an academic degree as a programmer;
nowadays or in future more and more people will be programmers by
necessity rather then active choice. 

But when has to realize when one is not good at particular thing, and
not blame the outside world. There is nothing shameless in that. I am
not good in Lisp programming; I learned it through hacking init file,
and I am not good at Emacs internals, I don't have time to sitt hours
and go through all if-defs and thousands of lines of lisp. I wish I
did. But when I don't know how to do something, I ask, and if they tell
me I don't understand it or have missed it, I don't tell them they
manual sux or code is horribly structured. Sometimes error is in our
selves, in this case, Dimech is probably not used to read the technical
manuals and that's not more.

Have you red The Glass Bead Game by Hesse? When people are out of
context, with other words, when we are talking of things we are not
experts in, we should take care, because we are not necessarily good at
one thing just because we are good at others. That is typical fallacy
when people are experts in one subject, get publicity, and then feel
urge to speak about subjects they are not experts in. It is especially
seen today when "influencers" who are (usually) experts in good looking,
are asked about all kind of comments, advices and how-to in diverse
magazines, programs etc.

Re: Auto Fill Comments

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-11-27 19:43]:
> I learned it through hacking init file, and I am not good at Emacs
> internals, I don't have time to sitt hours and go through all
> if-defs and thousands of lines of lisp. I wish I did. But when I
> don't know how to do something, I ask, and if they tell me I don't
> understand it or have missed it, I don't tell them they manual sux
> or code is horribly structured. Sometimes error is in our selves, in
> this case, Dimech is probably not used to read the technical manuals
> and that's not more.

I was asking different type of questions on #emacs IRC back in 2016,
and back then I did not know hot to look into references to get myself
Emacs insights. When one does not know where to look to there can be
bunch of references but one cannot find it. Today I have different
types of questions. There are progress stages for Emacs users.

I can remember `info' and `man' from 1999 and 2000, I had confusion
and did not understand why two systems. There was one time before that
where I was learning GNU/Linux exclusively from books. At the time I
did not know that `info' or `man' exists on system.

On command line I tried with: $ help, but that brought me at that time
incomprehensible list of bash commands.

There are various stages that users pass through until they get
it.

Jean

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 6:00 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Arthur Miller" <arthur.miller@live.com>
> Cc: "Christopher Dimech" <dimech@gmx.com>, help-gnu-emacs@gnu.org
> Subject: Re: Auto Fill Comments
>
> * Arthur Miller <arthur.miller@live.com> [2020-11-27 19:43]:
> > I learned it through hacking init file, and I am not good at Emacs
> > internals, I don't have time to sitt hours and go through all
> > if-defs and thousands of lines of lisp. I wish I did. But when I
> > don't know how to do something, I ask, and if they tell me I don't
> > understand it or have missed it, I don't tell them they manual sux
> > or code is horribly structured. Sometimes error is in our selves, in
> > this case, Dimech is probably not used to read the technical manuals
> > and that's not more.
>
> I was asking different type of questions on #emacs IRC back in 2016,
> and back then I did not know hot to look into references to get myself
> Emacs insights. When one does not know where to look to there can be
> bunch of references but one cannot find it. Today I have different
> types of questions. There are progress stages for Emacs users.

As things get more complex, figuring out how to look becomes problematic.
Today, looking far things has became a subject in itself.
If things get more complicated that you cannot understand it in
your lifetime (that time could come), then we all got to rethink
the whole thing, even though we don't like it.

> I can remember `info' and `man' from 1999 and 2000, I had confusion
> and did not understand why two systems. There was one time before that
> where I was learning GNU/Linux exclusively from books. At the time I
> did not know that `info' or `man' exists on system.
>
> On command line I tried with: $ help, but that brought me at that time
> incomprehensible list of bash commands.
>
> There are various stages that users pass through until they get
> it.
>
> Jean
>
>

Re: Auto Fill Comments

[Arthur Miller]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Friday, November 27, 2020 at 6:00 PM
>> From: "Jean Louis" <bugs@gnu.support>
>> To: "Arthur Miller" <arthur.miller@live.com>
>> Cc: "Christopher Dimech" <dimech@gmx.com>, help-gnu-emacs@gnu.org
>> Subject: Re: Auto Fill Comments
>>
>> * Arthur Miller <arthur.miller@live.com> [2020-11-27 19:43]:
>> > I learned it through hacking init file, and I am not good at Emacs
>> > internals, I don't have time to sitt hours and go through all
>> > if-defs and thousands of lines of lisp. I wish I did. But when I
>> > don't know how to do something, I ask, and if they tell me I don't
>> > understand it or have missed it, I don't tell them they manual sux
>> > or code is horribly structured. Sometimes error is in our selves, in
>> > this case, Dimech is probably not used to read the technical manuals
>> > and that's not more.
>>
>> I was asking different type of questions on #emacs IRC back in 2016,
>> and back then I did not know hot to look into references to get myself
>> Emacs insights. When one does not know where to look to there can be
>> bunch of references but one cannot find it. Today I have different
>> types of questions. There are progress stages for Emacs users.
>
> As things get more complex, figuring out how to look becomes problematic.
> Today, looking far things has became a subject in itself.
> If things get more complicated that you cannot understand it in
> your lifetime (that time could come), then we all got to rethink
> the whole thing, even though we don't like it.
Indeed, finding relevant information is not always trivial. But there is
also a skill of being focused and finding only those pieces of
information you need to accomplish what you need. When I made my first
hack to emacs, I had no idea how it does; I hacked it to accept
non-commentsin lisp; it wasn't liked on this list; nevertheless it was
just few lines of code to get it to do that. I still have not much
understanding of Emacs internals, and by now I have one idea approved
and taken into Emacs. We all get stuck; I particulary do; I am still not
very used to Lisp, and that felt incomprehensible for me when I was
reading it; but I went out on the web, red stuff, even found a book and
translated into English; that helped me understand Lisp and now I
understand Emacs Lisp manual much better and don't find it
incomprehensible (or at least hard) any more. Every language has its
idioms, jargon, etc; you have to get into it, if you wish to work with it.

Re: Auto Fill Comments

[Christopher Dimech]

> Sent: Friday, November 27, 2020 at 7:40 PM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org, "Jean Louis" <bugs@gnu.support>
> Subject: Re: Auto Fill Comments
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> >> Sent: Friday, November 27, 2020 at 6:00 PM
> >> From: "Jean Louis" <bugs@gnu.support>
> >> To: "Arthur Miller" <arthur.miller@live.com>
> >> Cc: "Christopher Dimech" <dimech@gmx.com>, help-gnu-emacs@gnu.org
> >> Subject: Re: Auto Fill Comments
> >>
> >> * Arthur Miller <arthur.miller@live.com> [2020-11-27 19:43]:
> >> > I learned it through hacking init file, and I am not good at Emacs
> >> > internals, I don't have time to sitt hours and go through all
> >> > if-defs and thousands of lines of lisp. I wish I did. But when I
> >> > don't know how to do something, I ask, and if they tell me I don't
> >> > understand it or have missed it, I don't tell them they manual sux
> >> > or code is horribly structured. Sometimes error is in our selves, in
> >> > this case, Dimech is probably not used to read the technical manuals
> >> > and that's not more.
> >>
> >> I was asking different type of questions on #emacs IRC back in 2016,
> >> and back then I did not know hot to look into references to get myself
> >> Emacs insights. When one does not know where to look to there can be
> >> bunch of references but one cannot find it. Today I have different
> >> types of questions. There are progress stages for Emacs users.
> >
> > As things get more complex, figuring out how to look becomes problematic.
> > Today, looking far things has became a subject in itself.
> > If things get more complicated that you cannot understand it in
> > your lifetime (that time could come), then we all got to rethink
> > the whole thing, even though we don't like it.
> Indeed, finding relevant information is not always trivial. But there is
> also a skill of being focused and finding only those pieces of
> information you need to accomplish what you need. When I made my first
> hack to emacs, I had no idea how it does; I hacked it to accept
> non-commentsin lisp; it wasn't liked on this list; nevertheless it was
> just few lines of code to get it to do that. I still have not much
> understanding of Emacs internals, and by now I have one idea approved
> and taken into Emacs. We all get stuck; I particulary do; I am still not
> very used to Lisp, and that felt incomprehensible for me when I was
> reading it; but I went out on the web, red stuff, even found a book and
> translated into English; that helped me understand Lisp and now I
> understand Emacs Lisp manual much better and don't find it
> incomprehensible (or at least hard) any more. Every language has its
> idioms, jargon, etc; you have to get into it, if you wish to work with it.

Agreed.  No qualms about that.

Re: Auto Fill Comments

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-11-27 19:43]:
>> I learned it through hacking init file, and I am not good at Emacs
>> internals, I don't have time to sitt hours and go through all
>> if-defs and thousands of lines of lisp. I wish I did. But when I
>> don't know how to do something, I ask, and if they tell me I don't
>> understand it or have missed it, I don't tell them they manual sux
>> or code is horribly structured. Sometimes error is in our selves, in
>> this case, Dimech is probably not used to read the technical manuals
>> and that's not more.
>
> I was asking different type of questions on #emacs IRC back in 2016,
> and back then I did not know hot to look into references to get myself
> Emacs insights. When one does not know where to look to there can be
> bunch of references but one cannot find it. Today I have different
> types of questions. There are progress stages for Emacs users.
>
> I can remember `info' and `man' from 1999 and 2000, I had confusion
> and did not understand why two systems. There was one time before that
> where I was learning GNU/Linux exclusively from books. At the time I
> did not know that `info' or `man' exists on system.

I remember myself too wondering why man and info back than. I never had
luxury of learning GNU/Linux from the books; I was too poor to invest in
those :-). I just looked into how things were done and was experimenting
and trying to get them do what I want them to do. If you look at my
emacs questions; I am still doing so :-)

> There are various stages that users pass through until they get
> it.
Indeed; so is with everything in life.

Re: RE: Auto Fill Comments

[tomas]

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

On Fri, Nov 27, 2020 at 01:47:08AM +0100, Christopher Dimech wrote:
> The manuals should be rewritten [...]

By whom? How? Who's the boss?

Cheers
 - t

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

Re: RE: Auto Fill Comments

[Jean Louis]

* tomas@tuxteam.de <tomas@tuxteam.de> [2020-11-27 11:49]:
> On Fri, Nov 27, 2020 at 01:47:08AM +0100, Christopher Dimech wrote:
> > The manuals should be rewritten [...]
> 
> By whom? How? Who's the boss?

Manuals are licensed under free documentation license so that people
may change or rewrite it.

Contributions are better, some practical suggestion on what exactly to
improve.

Re: Auto Fill Comments

[Stefan Monnier]

>> The manuals should be rewritten [...]
> By whom? How? Who's the boss?

Actually, the issue is not "who should be allowed" but "who would be able".


        Stefan

Re: Auto Fill Comments

[Stefan Monnier]

> (add-hook 'text-mode-hook
>    '(lambda()

Same here; please don't quote lambdas.


        Stefan

Re: Auto Fill Comments

[Stefan Monnier]

> We currently have just a hook to text-mode
> (add-hook 'text-mode-hook
>    '(lambda()

Please don't quote your lambdas.


        Stefan