Fwd: How do I go about debugging my Elisp code?

Fwd: How do I go about debugging my Elisp code?

[Davin Pearson]

---------- Forwarded message ---------
From: Davin Pearson <davin.pearson@gmail.com>
Date: Sat, 8 Jan 2022 at 18:20
Subject: How do I go about debugging my Elisp code?
To: emacs-devel <emacs-devel@gnu.org>

I sent this email to the google group
gnu.emacs.help but got no reply :-(

My problem is with the GNU Elisp Debugger...
When it comes up with a back trace it notifies you of the
problematic line of code but doesn't tell you which line or file
the error comes from.

What I have to do with this is to put debugger checkpoints on
every second line of Elisp code.  At least that gives you the
location of the error message, by looking at the *Messages*
buffer you can see the last checkpoint before the debugger
was entered...

See the file at the following URL location for an example.
In this file debug lines are commented out like so
;;(message "#Monkey-Man:123:")

http://davinpearson.nz/binaries/dmp-padderise2.el
<http://davinpearson.nz/binaries/dmp-padderise.el>

Here is my choice of syntax highlighting so that
my checkpoints appear in a dimmer face so they
don't unnecessarily clutter up the screen.

http://davinpearson.nz/binaries/screenshot.png

Executing the command in this file called dmp-padderise2.el:
M-x dmp-padderise--uncomment-hash-lines makes all the debug lines
visible to the Elisp system.  Executing the following command:
M-x dmp-padderise--comment-hash-lines comments out the debug lines.

Is there a better way to hunt down error messages?

Could someone email me a hyperlink to a superior debugging
system?

Re: Fwd: How do I go about debugging my Elisp code?

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

Davin Pearson wrote:

> I sent this email to the google group
> gnu.emacs.help but got no reply :-(

Yeah, that doesn't work anymore ...

"How do I go about debugging my Elisp code?"

Start by byte-compiling all the source ... Example: [1]

Then fix all errors and warnings ...

Then do

    (require 'checkdoc)

    (setq checkdoc-permit-comma-termination-flag t)

    (defun check-package-style ()
      (interactive)
      (let ((msg "Style check..."))
        (message msg)
        (checkdoc-current-buffer t) ; TAKE-NOTES
        (message "%sdone" msg) ))
    (defalias 'check-style #'check-package-style)

and fix everything that isn't related to it being a package,
unless it is a package, of course ;)

When everything is fixed ... THINK!

After that, if the problem remains, ask here :)

[1] https://dataswamp.org/~incal/emacs-init/Makefile

-- 
underground experts united
https://dataswamp.org/~incal

Re: Fwd: How do I go about debugging my Elisp code?

[Michael Heerdegen]

Davin Pearson <davin.pearson@gmail.com> writes:

> My problem is with the GNU Elisp Debugger...

Do we speak about Edebug or about the debugger living in the *Backtrace*
buffer?

Michael.

Re: Fwd: How do I go about debugging my Elisp code?

[Marcin Borkowski]

On 2022-01-13, at 02:22, Davin Pearson <davin.pearson@gmail.com> wrote:

> My problem is with the GNU Elisp Debugger...

Have you tried Edebug?


-- 
Marcin Borkowski
http://mbork.pl

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

I join to advise by Michael from Sweden as to make it a proper
package, use byte-compiler messages and warnings first.

You could use M-x emacs-lisp-byte-compile to find various warnings and
that is also for debugging purposes.

What I often do is instrumenting the function for Edebug and using
xref package to move from function to function.

Here is the method:

1. First find the function which you suspect or wish to debug, or the
   one which you are invoking.

2. Press C-u for prefix followed by C-M-x within the function. This
   will instrument the function for Edebug.

3. Run the function to begin the process. Once instrumenting process
   begins, click "n" for next and verify various values and how
   function is executed. You will find out what is wrong.

4. If you see that function is calling other function where you think
   that problem exists, instrument that other function as well.

5. To remove instrumentation use M-x edebug-remove-instrumentation and
   remove functions which you don't want to inspect any more.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Davin Pearson <davin.pearson@gmail.com> [2022-01-13 04:27]:
> http://davinpearson.nz/binaries/dmp-padderise2.el

After the first review of that file, I can see "Copyright" related to
your name. However, that makes the software proprietary. Because it
does change the Emacs, such software is incompatible with the Emacs
License. If it would be internal only, that would be fine. But as soon
as you publish it, you would need to comply to the license so that
your software becomes compatible legally.

One good way to comply is the package I made for friend from Sweden:

your hjälpsam Package Header Assistant
https://hyperscope.link/3/7/7/3/0/Your-hjälpsam-Package-Header-Assistant-37730.html

You may as well look into almost every ELPA package to find how
package header should look like.

Another way to understand it is to invoke C-h C-c and search for terms
"How to Apply These Terms to Your New Programs" as that is the Emacs
license.

Thanks for your patience and I hope for your insight into this matter.

In relation to technical assistance and related to your package, you
wrote "bugs: none" but I am not sure about it. Don't rush. Bugs they
come.

I have done M-x emacs-lisp-byte-compile on your file and result is
below. I recommend looking into those warnings. And I can assure you
that file may be compiled without any warnings. So try to minimize
those warnings.

\f
Compiling file /home/data1/protected/tmp/mozilla_admin0/dmp-padderise2.el at Fri Jan 14 16:39:25 2022

In zippy:
dmp-padderise2.el:44:5: Warning: reference to free variable ‘calamansi’

In dmp-padderise--inside-comment-or-string-p:
dmp-padderise2.el:63:51: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-padderise--inside-comment-p:
dmp-padderise2.el:86:15: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-padderise--deletes-comment-lines:
dmp-padderise2.el:153:31: Warning: assignment to free variable
    ‘dmp-comment-line-regexp’
dmp-padderise2.el:153:13: Warning: reference to free variable
    ‘dmp-comment-line-regexp’

In dmp-padderise--deletes-hash-lines:
dmp-padderise2.el:176:25: Warning: ‘incf’ is an obsolete alias (as of 27.1);
    use ‘cl-incf’ instead.

In dmp-padderise--comment-hash-lines:
dmp-padderise2.el:204:56: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:212:15: Warning: assignment to free variable ‘p0’
dmp-padderise2.el:216:15: Warning: assignment to free variable ‘p1’
dmp-padderise2.el:218:24: Warning: reference to free variable ‘p0’
dmp-padderise2.el:218:27: Warning: reference to free variable ‘p1’

In dmp-padderise--uncomment-hash-lines:
dmp-padderise2.el:230:11: Warning: assignment to free variable ‘count’
dmp-padderise2.el:234:135: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:247:4: Warning: reference to free variable ‘condition-case’
dmp-padderise2.el:247:19: Warning: reference to free variable ‘err4’
dmp-padderise2.el:250:18: Warning: reference to free variable ‘old-ptr’
dmp-padderise2.el:250:26: Warning: reference to free variable ‘new-ptr’
dmp-padderise2.el:251:18: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:253:48: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:255:32: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:255:48: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-gulp-code--safe:
dmp-padderise2.el:264:21: Warning: reference to free variable ‘old-ptr’
dmp-padderise2.el:264:29: Warning: reference to free variable ‘new-ptr’
dmp-padderise2.el:268:51: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-padderise--inside-symbol:
dmp-padderise2.el:286:38: Warning: ‘block’ is an obsolete alias (as of 27.1);
    use ‘cl-block’ instead.
dmp-padderise2.el:314:24: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:305:36: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:312:22: Warning: ‘return’ is an obsolete alias (as of 27.1);
    use ‘cl-return’ instead.
dmp-padderise2.el:318:20: Warning: ‘return’ is an obsolete alias (as of 27.1);
    use ‘cl-return’ instead.

In dmp-padderise--turn-one-line-to-many-lines:
dmp-padderise2.el:328:43: Warning: reference to free variable
    ‘*dmp-defun-outer-regexp*’
dmp-padderise2.el:331:30: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:331:30: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.

In dmp-padderise--wrap-spaces-around-inner-sexps:
dmp-padderise2.el:416:53: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:442:27: Warning: assignment to free variable
    ‘keyword-symbol’
dmp-padderise2.el:447:20: Warning: reference to free variable ‘keyword-symbol’

In dmp-padderise--re-search-forward:
dmp-padderise2.el:735:25: Warning: assignment to free variable ‘done’
dmp-padderise2.el:487:47: Warning: reference to free variable
    ‘*dmp-defun-outer-regexp*’
dmp-padderise2.el:532:41: Warning: reference to free variable ‘points-list’
dmp-padderise2.el:558:37: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:632:36: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:661:23: Warning: assignment to free variable ‘p0’
dmp-padderise2.el:665:23: Warning: assignment to free variable ‘p1’
dmp-padderise2.el:667:49: Warning: reference to free variable ‘p0’
dmp-padderise2.el:667:52: Warning: reference to free variable ‘p1’
dmp-padderise2.el:669:35: Warning: assignment to free variable ‘str’
dmp-padderise2.el:669:35: Warning: reference to free variable ‘str’
dmp-padderise2.el:745:25: Warning: reference to free variable ‘done’

In dmp-padderise--adder-whitespace-before-symbol:
dmp-padderise2.el:773:55: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:785:30: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’

In dmp-splat-symbol-sexp:
dmp-padderise2.el:807:23: Warning: ‘end-of-buffer’ is for interactive use
    only; use ‘(goto-char (point-max))’ instead.

In dmp-padderise--king-splodge:
dmp-padderise2.el:828:17: Warning: assignment to free variable ‘ket’
dmp-padderise2.el:836:19: Warning: assignment to free variable ‘bra’
dmp-padderise2.el:837:21: Warning: reference to free variable ‘bra’
dmp-padderise2.el:837:25: Warning: reference to free variable ‘ket’

In dmp-padderise--create-hashcodes:
dmp-padderise2.el:889:12: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:887:82: Warning: ‘incf’ is an obsolete alias (as of 27.1);
    use ‘cl-incf’ instead.

In dmp-padderise--add-gaps-to-m4-stuff:
dmp-padderise2.el:954:8: Warning: ‘beginning-of-buffer’ is for interactive use
    only; use ‘(goto-char (point-min))’ instead.
dmp-padderise2.el:995:17: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:995:17: Warning: ‘beginning-of-buffer’ is for interactive
    use only; use ‘(goto-char (point-min))’ instead.

In dmp-padderise--bra+ket:
dmp-padderise2.el:1044:12: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1044:12: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1044:12: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1044:12: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.

In dmp-padderise--skip-based-on-keyword--defun:
dmp-padderise2.el:1055:17: Warning: assignment to free variable ‘p0’
dmp-padderise2.el:1078:16: Warning: reference to free variable ‘p0’
dmp-padderise2.el:1116:17: Warning: assignment to free variable ‘endy’
dmp-padderise2.el:1061:37: Warning: reference to free variable
    ‘*dmp-defun-inner-regexp*’
dmp-padderise2.el:1063:24: Warning: assignment to free variable ‘skip’
dmp-padderise2.el:1066:17: Warning: reference to free variable ‘skip’
dmp-padderise2.el:1066:17: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1106:15: Warning: assignment to free variable ‘count’
dmp-padderise2.el:1112:17: Warning: reference to free variable ‘count’

In dmp-padderise--doit:
dmp-padderise2.el:1130:11: Warning: assignment to free variable ‘ptr2’
dmp-padderise2.el:1139:11: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1139:16: Warning: ‘remove-if-not’ is an obsolete function
    (as of 27.1); use ‘cl-remove-if-not’ instead.
dmp-padderise2.el:1146:23: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1156:13: Warning: assignment to free variable ‘*file-name*’

In dmp-padderise--endy:
dmp-padderise2.el:1201:6: Warning: dmp-padderise--re-search-forward called
    with 3 arguments, but accepts only 1

In dmp-padderise--split-el-files:
dmp-padderise2.el:1209:12: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1213:25: Warning: reference to free variable ‘ptr’

In dmp-padderise--scan-for-vspaces:
dmp-padderise2.el:1296:20: Warning: assignment to free variable
    ‘dmp-padderise--listing*’
dmp-padderise2.el:1268:12: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1270:22: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1300:53: Warning: assignment to free variable ‘buf’
dmp-padderise2.el:1296:10: Warning: reference to free variable ‘buf’
dmp-padderise2.el:1274:18: Warning: reference to free variable
    ‘*dmp-padderise--listing*’
dmp-padderise2.el:1292:49: Warning: assignment to free variable ‘p’
dmp-padderise2.el:1290:32: Warning: reference to free variable ‘p’
dmp-padderise2.el:1302:17: Warning: assignment to free variable ‘str’
dmp-padderise2.el:1302:17: Warning: reference to free variable
    ‘dmp-padderise--listing*’
dmp-padderise2.el:1300:41: Warning: reference to free variable ‘str’

In dmp-padderise--delete-hash-comments:
dmp-padderise2.el:1321:16: Warning: ‘remove-if’ is an obsolete function (as of
    27.1); use ‘cl-remove-if’ instead.
dmp-padderise2.el:1333:42: Warning: assignment to free variable ‘regexp-inner’
dmp-padderise2.el:1333:42: Warning: reference to free variable ‘regexp-inner’
dmp-padderise2.el:1355:35: Warning: assignment to free variable ‘regexp-outer’
dmp-padderise2.el:1373:22: Warning: reference to free variable ‘regexp-outer’
dmp-padderise2.el:1375:10: Warning: ‘incf’ is an obsolete alias (as of 27.1);
    use ‘cl-incf’ instead.

In buffer->sexp:
dmp-padderise2.el:1446:13: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1442:21: Warning: assignment to free variable ‘done’
dmp-padderise2.el:1442:21: Warning: reference to free variable ‘done’
dmp-padderise2.el:1436:48: Warning: assignment to free variable ‘str’
dmp-padderise2.el:1436:65: Warning: assignment to free variable ‘form’
dmp-padderise2.el:1443:17: Warning: reference to free variable ‘str’
dmp-padderise2.el:1444:17: Warning: reference to free variable ‘form’
dmp-padderise2.el:1446:27: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1453:67: Warning: assignment to free variable ‘result-pairs’
dmp-padderise2.el:1453:27: Warning: reference to free variable ‘result-pairs’
dmp-padderise2.el:1453:44: Warning: assignment to free variable
    ‘output-of-string->sexp’
dmp-padderise2.el:1453:8: Warning: assignment to free variable
    ‘result-delve-deep’

In delve-deep:
dmp-padderise2.el:1460:10: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1462:20: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1469:33: Warning: assignment to free variable ‘car’
dmp-padderise2.el:1469:33: Warning: reference to free variable ‘car’
dmp-padderise2.el:1465:15: Warning: assignment to free variable ‘comment’
dmp-padderise2.el:1469:15: Warning: assignment to free variable ‘code’
dmp-padderise2.el:1472:34: Warning: reference to free variable ‘code’
dmp-padderise2.el:1472:11: Warning: assignment to free variable ‘result’
dmp-padderise2.el:1476:8: Warning: assignment to free variable ‘result’

In delve-deep-str:
dmp-padderise2.el:1491:12: Warning: assignment to free variable ‘ptr’
dmp-padderise2.el:1495:22: Warning: reference to free variable ‘ptr’
dmp-padderise2.el:1501:9: Warning: assignment to free variable
    ‘**dmp-padderise--bra-less-bra-ket**’
dmp-padderise2.el:1502:9: Warning: assignment to free variable
    ‘**dmp-padderise--bra-plus-bra-ket**’
dmp-padderise2.el:1503:9: Warning: assignment to free variable
    ‘**dmp-padderise--ket**’
dmp-padderise2.el:1504:37: Warning: reference to free variable
    ‘**dmp-padderise--bra-less-bra-ket**’
dmp-padderise2.el:1513:25: Warning: assignment to free variable ‘sexp’
dmp-padderise2.el:1512:8: Warning: reference to free variable ‘sexp’
dmp-padderise2.el:1545:36: Warning: assignment to free variable
    ‘dmp-padderise--list’
dmp-padderise2.el:1536:19: Warning: assignment to free variable ‘p-0’
dmp-padderise2.el:1540:19: Warning: assignment to free variable ‘p-1’
dmp-padderise2.el:1542:21: Warning: reference to free variable ‘p-0’
dmp-padderise2.el:1542:25: Warning: reference to free variable ‘p-1’
dmp-padderise2.el:1554:33: Warning: reference to free variable
    ‘dmp-padderise--list’
dmp-padderise2.el:1556:51: Warning: assignment to free variable ‘popped’
dmp-padderise2.el:1556:51: Warning: reference to free variable ‘popped’
dmp-padderise2.el:1556:51: Warning: ‘decf’ is an obsolete alias (as of 27.1);
    use ‘cl-decf’ instead.
dmp-padderise2.el:1571:7: Warning: ‘assert’ is an obsolete alias (as of 27.1);
    use ‘cl-assert’ instead.
dmp-padderise2.el:1579:15: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1595:16: Warning: ‘assert’ is an obsolete alias (as of
    27.1); use ‘cl-assert’ instead.
dmp-padderise2.el:1602:30: Warning: assignment to free variable ‘match’
dmp-padderise2.el:1602:30: Warning: reference to free variable ‘match’
dmp-padderise2.el:1614:18: Warning: assignment to free variable ‘p0’
dmp-padderise2.el:1618:18: Warning: assignment to free variable ‘p1’
dmp-padderise2.el:1620:22: Warning: reference to free variable ‘p0’
dmp-padderise2.el:1620:25: Warning: reference to free variable ‘p1’

In dmp-padderise--doit:
dmp-padderise2.el:1640:8: Warning: function ‘dmp-padderise--doit’ defined
    multiple times in this file
dmp-padderise2.el:1747:3: Error: Invalid read syntax: ")", 1747, 3


To run that file alone is impossible as it gives me error:

cons: Symbol’s function definition is void: dmp-canonicalise

I am invoking your file M-x eval-buffer as there is no other
recommended way.

You have (progn) statement at beginning, and I recommend putting that
statement in a function, and that function to become (interactive) so
that it may be invoked. 

Recommended reading and recommended to apply:
(info "(elisp) Packaging Basics") <---- evaluate here to reach to info
file.

Some other notes related to your package:
;; Keywords: Cull Size Quota

Keywords cannot be just any keywords, those shall be keywords as
listed by function M-x finder-list-keywords, such as following:

abbrev	      abbreviation handling, typing shortcuts, and macros
bib	      bibliography processors
c	      C and related programming languages
calendar      calendar and time management tools
comm	      communications, networking, and remote file access
convenience   convenience features for faster editing
data	      editing data (non-text) files
docs	      Emacs documentation facilities
emulations    emulations of other editors
extensions    Emacs Lisp language extensions
faces	      fonts and colors for text
files	      file editing and manipulation
frames	      Emacs frames and window systems
games	      games, jokes and amusements
hardware      interfacing with system hardware
help	      Emacs help systems
hypermedia    links between text or other media types
i18n	      internationalization and character-set support
internal      code for Emacs internals, build process, defaults
languages     specialized modes for editing programming languages
lisp	      Lisp support, including Emacs Lisp
local	      code local to your site
maint	      Emacs development tools and aids
mail	      email reading and posting
matching      searching, matching, and sorting
mouse	      mouse support
multimedia    images and sound
news	      USENET news reading and posting
outlines      hierarchical outlining and note taking
processes     processes, subshells, and compilation
terminals     text terminals (ttys)
tex	      the TeX document formatter
tools	      programming tools
unix	      UNIX feature interfaces and emulators
vc	      version control
wp	      word processing


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

> * Davin Pearson <davin.pearson@gmail.com> [2022-01-13 04:27]:
>> http://davinpearson.nz/binaries/dmp-padderise2.el
>
> After the first review of that file, I can see "Copyright" related to
> your name. However, that makes the software proprietary.

Nonsense.  It is perfectly fine to have individual authors and
contributors as copyright holders.  Only if a package wants to become
part of emacs (GNU ELPA), one has to assign the copyright to the FSF.
But it would still be fine for NonGNU ELPA if it had a proper license
statement (which is the actual missing part).

However, that file is basically a demo for debugging by adding a printed
message after each line with no intention of becoming part of emacs, so
¯\_(ツ)_/¯.

Bye,
Tassilo

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2022-01-14 18:06]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Davin Pearson <davin.pearson@gmail.com> [2022-01-13 04:27]:
> >> http://davinpearson.nz/binaries/dmp-padderise2.el
> >
> > After the first review of that file, I can see "Copyright" related to
> > your name. However, that makes the software proprietary.
> 
> Nonsense.

Maybe there is something you did not understand, or I have expressed
myself unsufficiently. That is why you call it "nonsense". When person
does not provide a license reference in any kind of software,
including in Emacs configuration files (which is software), but says
that it is copyrighted, in absence of the free license that software
is proprietary. Do you understand it?

> It is perfectly fine to have individual authors and contributors as
> copyright holders.

That is because I have not expressed myself sufficiently. It really
does not matter who is copyright holder.  What matters is that there
is no compatible free software license in the software. That is what I
forgot to mention.

> Only if a package wants to become part of emacs (GNU ELPA), one has
> to assign the copyright to the FSF.

I did not refer to assigning copyrights to FSF. I have referred to how
package should look like in relation to legality. Who has copyrights
is there not relevant. What is relevant, and what I missed to describe
enough is the absence of compatible license reference.

I am assuming that author wanted to provide such reference and that
his m4 macros are not finished.

> But it would still be fine for NonGNU ELPA if it had a proper
> license statement (which is the actual missing part).

Licensing requirements are not related to ELPA or NonGNU ELPA or any
repository. They are generally related to the license under which
Emacs is issued, so license has to be compatible. It is not relevant
how is software published.

> However, that file is basically a demo for debugging by adding a printed
> message after each line with no intention of becoming part of emacs, so
> ¯\_(ツ)_/¯.

That is incorrect. Software modifies Emacs, thus has to be compatible
to same free software license under which Emacs is issues.

The same is valid for all other software that is modifying Emacs.

In other words, when somebody creates a function for Emacs it is
software modifying Emacs and shall be under compatible software
license. Like GNU GPL v3+


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

Hi Jean,

I think we both agree that the missing license is the main issue, not
the Copyright notice.

>> However, that file is basically a demo for debugging by adding a
>> printed message after each line with no intention of becoming part of
>> emacs, so ¯\_(ツ)_/¯.
>
> That is incorrect. Software modifies Emacs, thus has to be compatible
> to same free software license under which Emacs is issues.
>
> The same is valid for all other software that is modifying Emacs.
>
> In other words, when somebody creates a function for Emacs it is
> software modifying Emacs and shall be under compatible software
> license. Like GNU GPL v3+

I don't think that an emacs package is a modification of emacs itself or
a derivative work.  Rather the package links to emacs, i.e., emacs is a
kind of "standard library" for all emacs packages.  But even then, it
needs to have a license compatible with emacs' license, yes.

But I'm not sure if merely posting some basically private code somewhere
on a private homepage or on some pastebin requires you to add a license
notice.  I mean, hundreds share their .emacs file on the web without
thinking about licensing.

Bye,
Tassilo

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2022-01-14 19:43]:
> I think we both agree that the missing license is the main issue, not
> the Copyright notice.

Those terms are related. If there is copyright notice and otherwise
license missing, then it is automatically proprietary, that is how it
is in most of countries.

If there is however, copyright notice, but license somewhere else in
the directory of the file, then that is already good. But the GNU GPL
suggests (maybe requires) the notice in each file, as files may be
singly distributed. Then how would the recipient know under which
license it was issued if the notice is not in the file.

> I don't think that an emacs package is a modification of emacs itself or
> a derivative work.

If you modify variable you are modifying Emacs. If you create a
function than such software modifies Emacs as function did not exist
in Emacs. It creates new function. Thus new function is modification
of Emacs itself.

You have to review the license for full understanding.

> Rather the package links to emacs, i.e., emacs is a kind of
> "standard library" for all emacs packages.

It is not enough of the excuse. 😝 Creating a function or program,
small or large, meant for Emacs Lisp means it will modify Emacs as it
adds new function, thus such function shall be compatible to Emacs
license.

Yes, that means all of the init files, configurations and snippets
should carry such notices of being compatible, otherwise they are not
and are automatically proprietary.

> But I'm not sure if merely posting some basically private code somewhere
> on a private homepage or on some pastebin requires you to add a license
> notice.

It does, otherwise it is considered incompatible to Emacs as it is
automatically proprietary.

> I mean, hundreds share their .emacs file on the web without thinking
> about licensing.

That is exactly the reason why I am mentioning this all.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

>> I don't think that an emacs package is a modification of emacs itself
>> or a derivative work.
>
> If you modify variable you are modifying Emacs.

So if I want to give some help-searching user the hint to reproduce an
error with debug-on-error set to t, I should write my reply as given in
the below?

--8<---------------cut here---------------start------------->8---
Could you please try using the following added to your .emacs?

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
(setq debug-on-error t)
--8<---------------cut here---------------end--------------->8---

I mean, according to your reasoning, I'm publishing a modification of
emacs here.

> If you create a function than such software modifies Emacs as function
> did not exist in Emacs.  It creates new function.  Thus new function
> is modification of Emacs itself.

IMHO, modification is usually meant as copying and adapting code.
Setting a variable is more or less configuration.  An interesting aspect
are advices which allow modifying existing functions without physically
touching their source code.

>> But I'm not sure if merely posting some basically private code
>> somewhere on a private homepage or on some pastebin requires you to
>> add a license notice.
>
> It does, otherwise it is considered incompatible to Emacs as it is
> automatically proprietary.

Well, I'd say that's kind of a grey area.  Of course, elisp code that is
published on the interwebs without specifying a compatible license
cannot be subject for inclusion or linkage in my super-duper elisp
package which I intend to publish on some package archive.  However, I
wouldn't go so far to accuse someone posting his ~/.emacs or some other
code snippets of license infringement.

Bye,
Tassilo

Re: Fwd: How do I go about debugging my Elisp code?

[Yuri Khan]

On Fri, 14 Jan 2022 at 20:48, Jean Louis <bugs@gnu.support> wrote:

> * Davin Pearson <davin.pearson@gmail.com> [2022-01-13 04:27]:
> > http://davinpearson.nz/binaries/dmp-padderise2.el
>
> After the first review of that file, I can see "Copyright" related to
> your name. However, that makes the software proprietary. Because it
> does change the Emacs, such software is incompatible with the Emacs
> License. If it would be internal only, that would be fine. But as soon
> as you publish it, you would need to comply to the license so that
> your software becomes compatible legally.

Hey, that’s unfair.

* A guy asks the list for help in debugging their personal, private
use piece of code.
* You come and suggest that they publish it as a package.
* They do, and then you start insisting that package has to be
compatible with the Emacs license.

Basically you tricked the OP into publishing their code and are
bullying them into releasing that code under a Free license.

As published, the code does not work. You cannot use it, therefore you
are not its User as defined by GPL. As you are not its user, you do
not have the rights that the GPL grants to users. Problem solved.

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2022-01-14 20:42]:
> On Fri, 14 Jan 2022 at 20:48, Jean Louis <bugs@gnu.support> wrote:
> 
> > * Davin Pearson <davin.pearson@gmail.com> [2022-01-13 04:27]:
> > > http://davinpearson.nz/binaries/dmp-padderise2.el
> >
> > After the first review of that file, I can see "Copyright" related to
> > your name. However, that makes the software proprietary. Because it
> > does change the Emacs, such software is incompatible with the Emacs
> > License. If it would be internal only, that would be fine. But as soon
> > as you publish it, you would need to comply to the license so that
> > your software becomes compatible legally.

While your comment sounds funny to me, I wish to answer it in more
serious manner as not to confuse the public that is reading it.

> Hey, that’s unfair.
> 
> * A guy asks the list for help in debugging their personal, private
> use piece of code.

By doing so the program was published.

> * You come and suggest that they publish it as a package.

That is right in itself, we and you know, it is good way of making
programs.

> * They do, and then you start insisting that package has to be
> compatible with the Emacs license.

I did not see any conformant package.

Licensing issue is separate. And yes, code should be licensed
properly. If we are discussing the code we are resharing it.

> Basically you tricked the OP into publishing their code and are
> bullying them into releasing that code under a Free license.

There is no "tricked" at hand, that is your exaggerated personal
impression which I cannot share neither agree to it.

There is no "bullying" involved at all. Your exaggeration I do not
find proper.

> As published, the code does not work. You cannot use it, therefore you
> are not its User as defined by GPL. As you are not its user, you do
> not have the rights that the GPL grants to users. Problem solved.

Code does not need to work to be authored and thus automatically or
implicitly licensed. Code may be even written in yet unknown
programming language. It is not relevant if code is functional or not
functional.

There are Emacs packages not any more functional with today's version,
they are nevertheless copyrighted and copyright implies some terms. 

Terms must be clear with any code published for Emacs as it is under
the GNU GPL license. 

It is up to writers and authors to understand the license, and that is
important for future of free software. 

Sadly, free software licenses were read and easier understood much
widely before 20 years than it is now. I will keep nudging.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2022-01-14 20:47]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> I don't think that an emacs package is a modification of emacs itself
> >> or a derivative work.
> >
> > If you modify variable you are modifying Emacs.
> 
> So if I want to give some help-searching user the hint to reproduce an
> error with debug-on-error set to t, I should write my reply as given in
> the below?

I would assume that your minimal contributions to Emacs are under the
same license as Emacs and simply include it how it is in my code if I
wish, but then I would say it was authored by yourself. Then in case
of complaint from your side I could adapt it how you and me think it
is alright.

It is good to be practical. 

> I mean, according to your reasoning, I'm publishing a modification of
> emacs here.

Which is right. Though, see above.

> > If you create a function than such software modifies Emacs as function
> > did not exist in Emacs.  It creates new function.  Thus new function
> > is modification of Emacs itself.
> 
> IMHO, modification is usually meant as copying and adapting code.
> Setting a variable is more or less configuration.  An interesting aspect
> are advices which allow modifying existing functions without physically
> touching their source code.

Your code can be nothing else but setting variables. If your program
cannot run without main part named Emacs, than such modification
represent new work, and is thus modification of Emacs and has to carry
the license.

I am pointing to it for the exact same reason like you, just from
different angle. Many people are not aware of it. But as I said, small
parts of code on mailing list I would re-use if necessary in GNU GPL
package while giving credit to author until some complaint would come. 

> >> But I'm not sure if merely posting some basically private code
> >> somewhere on a private homepage or on some pastebin requires you to
> >> add a license notice.
> >
> > It does, otherwise it is considered incompatible to Emacs as it is
> > automatically proprietary.
> 
> Well, I'd say that's kind of a grey area.  Of course, elisp code that is
> published on the interwebs without specifying a compatible license
> cannot be subject for inclusion or linkage in my super-duper elisp
> package which I intend to publish on some package archive.  However, I
> wouldn't go so far to accuse someone posting his ~/.emacs or some other
> code snippets of license infringement.

Though yes, ~/.emacs published is code modifying Emacs and shall be
published under the free software license compatible with Emacs. 

That it is commonly not indicated does not make it less infringement.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Marcin Borkowski]

On 2022-01-14, at 17:53, Jean Louis <bugs@gnu.support> wrote:

> Yes, that means all of the init files, configurations and snippets
> should carry such notices of being compatible, otherwise they are not
> and are automatically proprietary.

If this were true, wouldn't it imply that most of
emacs.stackexchange.com is copyright infringement?

--8<---------------cut here---------------start------------->8---
Subscriber Content

You agree that any and all content, including without limitation any and
all text, graphics, logos, tools, photographs, images, illustrations,
software or source code, audio and video, animations, and product
feedback (collectively, “Content”) that you provide to the public
Network (collectively, “Subscriber Content”), is perpetually and
irrevocably licensed to Stack Overflow on a worldwide, royalty-free,
non-exclusive basis pursuant to Creative Commons licensing terms (CC
BY-SA 4.0), and you grant Stack Overflow the perpetual and irrevocable
right and license to access, use, process, copy, distribute, export,
display and to commercially exploit such Subscriber Content, [...]
--8<---------------cut here---------------end--------------->8---

(from https://stackoverflow.com/legal/terms-of-service#licensing)

If so, I'll probably want to decide whether I find it ridiculous,
hilarious or scary.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: Fwd: How do I go about debugging my Elisp code?

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

>> So if I want to give some help-searching user the hint to reproduce
>> an error with debug-on-error set to t, I should write my reply as
>> given in the below?
>
> I would assume that your minimal contributions to Emacs are under the
> same license as Emacs and simply include it how it is in my code if I
> wish, but then I would say it was authored by yourself.  Then in case
> of complaint from your side I could adapt it how you and me think it
> is alright.
>
> It is good to be practical. 

I guess with elisp, it will never ever happen that the author of some
code in some posting will complain.  But noting down the author along
the code is a very good idea because of copyright, i.e., when you later
want to contribute your package to emacs or publish it on GNU ELPA.

>> IMHO, modification is usually meant as copying and adapting code.
>> Setting a variable is more or less configuration.  An interesting
>> aspect are advices which allow modifying existing functions without
>> physically touching their source code.
>
> Your code can be nothing else but setting variables.  If your program
> cannot run without main part named Emacs, than such modification
> represent new work, and is thus modification of Emacs and has to carry
> the license.

I guess there must be some degree of non-trivialness before licensing
becomes important, no?

Bye,
Tassilo

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Marcin Borkowski <mbork@mbork.pl> [2022-01-14 21:56]:
> 
> On 2022-01-14, at 17:53, Jean Louis <bugs@gnu.support> wrote:
> 
> > Yes, that means all of the init files, configurations and snippets
> > should carry such notices of being compatible, otherwise they are not
> > and are automatically proprietary.
> 
> If this were true, wouldn't it imply that most of
> emacs.stackexchange.com is copyright infringement?

That code published on Emacs StackExchange is compatible to Emacs.

As you have referenced it below, code published on Stack Exchange is
under Creative Commons BY-SA 4.0., so your reference is here:
https://www.gnu.org/licenses/license-list.html#ccbysa

This is a copyleft free license that is good for artistic and
entertainment works, and educational works. Like all CC licenses, it
should not be used on software.

CC BY-SA 4.0 is one-way compatible with the GNU GPL version 3: this
means you may license your modified versions of CC BY-SA 4.0 materials
under GNU GPL version 3, but you may not relicense GPL 3 licensed
works under CC BY-SA 4.0.

Because Creative Commons lists only version 3 of the GNU GPL on its
compatible licenses list, it means that you can not license your
adapted CC BY-SA works under the terms of “GNU GPL version 3, or (at
your option) any later version.” However, Section 14 of the GNU GPL
version 3 allows licensors to specify a proxy to determine whether
future versions of the GNU GPL can be used. Therefore, if someone
adapts a CC BY-SA 4.0 work and incorporates it into a GNU GPL version
3 licensed project, they can specify Creative Commons as their proxy
(via http://creativecommons.org/compatiblelicenses) so that if and
when Creative Commons determines that a future version of the GNU GPL
is a compatible license, the adapted and combined work could be used
under that later version of the GNU GPL.


> --8<---------------cut here---------------start------------->8---
> Subscriber Content
> 
> You agree that any and all content, including without limitation any and
> all text, graphics, logos, tools, photographs, images, illustrations,
> software or source code, audio and video, animations, and product
> feedback (collectively, “Content”) that you provide to the public
> Network (collectively, “Subscriber Content”), is perpetually and
> irrevocably licensed to Stack Overflow on a worldwide, royalty-free,
> non-exclusive basis pursuant to Creative Commons licensing terms (CC
> BY-SA 4.0), and you grant Stack Overflow the perpetual and irrevocable
> right and license to access, use, process, copy, distribute, export,
> display and to commercially exploit such Subscriber Content, [...]
> --8<---------------cut here---------------end--------------->8---
> 
> (from https://stackoverflow.com/legal/terms-of-service#licensing)

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

>> If this were true, wouldn't it imply that most of
>> emacs.stackexchange.com is copyright infringement?
>
> That code published on Emacs StackExchange is compatible to Emacs.
>
> As you have referenced it below, code published on Stack Exchange is
> under Creative Commons BY-SA 4.0., so your reference is here:
> https://www.gnu.org/licenses/license-list.html#ccbysa
>
> This is a copyleft free license that is good for artistic and
> entertainment works, and educational works. Like all CC licenses, it
> should not be used on software.
>
> CC BY-SA 4.0 is one-way compatible with the GNU GPL version 3: this
> means you may license your modified versions of CC BY-SA 4.0 materials
> under GNU GPL version 3, but you may not relicense GPL 3 licensed
> works under CC BY-SA 4.0.

Aren't they doing exactly the latter when allowing elisp code to be
posted?  According to your argument, every elisp code is a modification
of emacs itself and therefore must have the same license (or at least
equivalent terms) as emacs.

Bye,
Tassilo

Re: Fwd: How do I go about debugging my Elisp code?

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

Jean Louis wrote:

> I join to advise by Michael from Sweden

Haha :D

> as to make it a proper package, use byte-compiler messages
> and warnings first.
>
> You could use M-x emacs-lisp-byte-compile to find various
> warnings and that is also for debugging purposes.
>
> What I often do is instrumenting the function for Edebug and
> using xref package to move from function to function.
>
> Here is the method:
>
> 1. First find the function which you suspect or wish to
>    debug, or the one which you are invoking.
>
> 2. Press C-u for prefix followed by C-M-x within the
>    function. This will instrument the function for Edebug.
>
> 3. Run the function to begin the process. Once instrumenting
>    process begins, click "n" for next and verify various
>    values and how function is executed. You will find out
>    what is wrong.
>
> 4. If you see that function is calling other function where
>    you think that problem exists, instrument that other
>    function as well.
>
> 5. To remove instrumentation use M-x
>    edebug-remove-instrumentation and remove functions which
>    you don't want to inspect any more.

... but good outline.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Fwd: How do I go about debugging my Elisp code?

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

Jean Louis wrote:

> One good way to comply is the package I made for friend from
> Sweden:
>
> your hjälpsam Package Header Assistant
> https://hyperscope.link/3/7/7/3/0/Your-hjälpsam-Package-Header-Assistant-37730.html

Hahaha :D

"hjälpsam" = helpful

-- 
underground experts united
https://dataswamp.org/~incal

NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

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

Tassilo Horn wrote:

> But it would still be fine for NonGNU ELPA if it had
> a proper license statement (which is the actual missing
> part).

What's this NonGNU ELPA I keep hearing about lately?

I only have GNU ELPA and MELPA and GNU ELPA is added by
default so I have just done

  (push '("melpa" . "https://melpa.org/packages/") package-archives)

so far.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Fwd: How do I go about debugging my Elisp code?

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

Marcin Borkowski wrote:

> Subscriber Content
>
> You agree that any and all content, including without limitation any and
> all text, graphics, logos, tools, photographs, images, illustrations,
> software or source code, audio and video, animations, and product
> feedback (collectively, “Content”) that you provide to the public
> Network (collectively, “Subscriber Content”), is perpetually and
> irrevocably licensed to Stack Overflow on a worldwide, royalty-free,
> non-exclusive basis pursuant to Creative Commons licensing terms (CC
> BY-SA 4.0), and you grant Stack Overflow the perpetual and irrevocable
> right and license to access, use, process, copy, distribute, export,
> display and to commercially exploit such Subscriber Content, [...]
>
> (from https://stackoverflow.com/legal/terms-of-service#licensing)
>
> If so, I'll probably want to decide whether I find it
> ridiculous, hilarious or scary.

Maybe there are just saying they take responsibility for what
is on their site? And they may have reasons to do so that
aren't "we're just greedy".

Not saying this is the case tho, just theorizing ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Fwd: How do I go about debugging my Elisp code?

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

Yuri Khan wrote:

> Hey, that’s unfair.
>
> * A guy asks the list for help in debugging their personal, private
> use piece of code.
> * You come and suggest that they publish it as a package.
> * They do, and then you start insisting that package has to be
> compatible with the Emacs license.

But isn't that a good idea?

> Basically you tricked the OP into publishing their code and
> are bullying them into releasing that code under
> a Free license.

Actually I don't think so, Jean isn't advanced enough to go
around tricking people ;)

> As published, the code does not work. You cannot use it,
> therefore you are not its User as defined by GPL. As you are
> not its user, you do not have the rights that the GPL grants
> to users. Problem solved.

Uhm, what was the problem now again?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Fwd: How do I go about debugging my Elisp code?

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

>> One good way to comply is the package I made for friend
>> from Sweden:
>>
>> your hjälpsam Package Header Assistant
>> https://hyperscope.link/3/7/7/3/0/Your-hjälpsam-Package-Header-Assistant-37730.html
>
> Hahaha :D
>
> "hjälpsam" = helpful

Very good!

Only this:

(defun package-header-ask-keywords ()
  "Ask author for package keywords."
  (let ((keywords '())
        (keyword))
    (while (string-match "[^[:blank:]]"
                         (setq keyword
                               (completing-read "Keywords: " (package-header-keywords) nil t)))
      (push keyword keywords))
    (when keywords
      (mapconcat 'identity (sort keywords #'string<) " "))))

In the prompt string, maybe it is a good idea to mention how
to quit? Type nothing just hit RET? Since/if every pack should
have at least one keyword, the first PS could be

  Keyword: [TAB to complete]

(note the singular form)

after that it could be

  Keyword: [RET to quit]

Then, remove duplicates from the result, I say this because
when I tried the software it took three times to figure out
that was how it worked, at first I thought it didn't register,
so when I finally quit it said

  Keywords: convenience convenience convenience

:)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2022-01-14 22:48]:
> Jean Louis <bugs@gnu.support> writes:
> 
> >> So if I want to give some help-searching user the hint to reproduce
> >> an error with debug-on-error set to t, I should write my reply as
> >> given in the below?
> >
> > I would assume that your minimal contributions to Emacs are under the
> > same license as Emacs and simply include it how it is in my code if I
> > wish, but then I would say it was authored by yourself.  Then in case
> > of complaint from your side I could adapt it how you and me think it
> > is alright.
> >
> > It is good to be practical. 
> 
> I guess with elisp, it will never ever happen that the author of some
> code in some posting will complain.  But noting down the author along
> the code is a very good idea because of copyright, i.e., when you later
> want to contribute your package to emacs or publish it on GNU ELPA.

Look at plethora of Emacs packages on various repositories, large
majority of them are properly licensed. This is because of policies
established at repository and their quick verification. Few are
improper or not adequate.

Those packages beyond repositories often lack licenses. They need
practical reminder.



Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2022-01-14 23:00]:
> > CC BY-SA 4.0 is one-way compatible with the GNU GPL version 3: this
> > means you may license your modified versions of CC BY-SA 4.0 materials
> > under GNU GPL version 3, but you may not relicense GPL 3 licensed
> > works under CC BY-SA 4.0.
> 
> Aren't they doing exactly the latter when allowing elisp code to be
> posted?

That question I don't get.

> According to your argument, every elisp code is a modification of
> emacs itself and therefore must have the same license (or at least
> equivalent terms) as emacs.

Yes. My understanding is  that CC BY-SA 4.0 license is compatible to
GPL 3+ and thus all contributions on Emacs StackExchange are
compatible to Emacs license, thus fine in that regard.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-15 02:32]:
> Tassilo Horn wrote:
> 
> > But it would still be fine for NonGNU ELPA if it had
> > a proper license statement (which is the actual missing
> > part).
> 
> What's this NonGNU ELPA I keep hearing about lately?

Maybe winter sleep took you too long.

NonGNU Emacs Lisp Package Archive is the answer to issues otherwise
not handled on MELPA, for example, this repository will include any
kind of packages but not steer users to vague licensed packages or
proprietary software.

More information: https://git.savannah.gnu.org/cgit/emacs/nongnu.git/plain/README.org

* Guidance for accepting packages

** We don't ask for copyright assignments to include packages in NonGNU ELPA.

** The Emacs maintainers will decide what packages to put in NonGNU ELPA.

** If an ELisp package follows the rules below,
  we can add it to NonGNU ELPA if we want to.  If the code doesn't
  follow them, we can change the code to follow them.  We may also
  change the code in NonGNU ELPA for other reasons, technical or not.
  After all, it is free software.

** For practical reasons, we usually refrain from making local changes
  to NonGNU ELPA packages, in order to simplify integration of future
  changes from the upstream version.

** The package's developers don't have an obligation to maintain the
  NonGNU ELPA version, but we would like to invite them to do that, or
  to cooperate and coordinate with us in doing that.  If you are the
  developer of a NonGNU ELPA package, or a package that might be added
  to NonGNU ELPA, and you're interested in maintaining it there, let's
  discuss it.

** Rules for a package to be acceptable in NonGNU ELPA

*** A NonGNU ELPA package must display its copyright notices and license
   notices clearly on each nontrivial file.  The notices do not have to
   follow the FSF conventions about their presentation.

   Software files need to carry a free license that is compatible with the
   GNU GPL version 3-or-later.  Which licenses qualify is stated in
   https://gnu.org/licenses/license-list.html.

   Manuals need to be under a free license that is compatible
   with the GNU FDL version 1.4-or-later.  Which licenses qualify is
   stated in https://gnu.org/licenses/license-list.html.

   All other documentation files, for users (manuals, help files, man
   pages, and so on), and for developers (program logic, change logs,
   and so on), can be under a license acceptable for manuals or a
   license acceptable for software files (see above).  We can agree
   with the package developers to include documentation published under
   other free licenses.

   Trivial files of just a few lines don't need to state a copyright or
   a license.

   Normally we don't include material other than software or
   documentation, but we can agree with the developers to include
   specific material.  If the material in question is an educational
   resource, then it can have a license compatible with GNU FDL version
   1.4 or one of the free Creative Commons licenses (CC-BY-SA, CC-BY or
   CC-0), or another free license at our discretion.  If the material is
   not an educational resource, it can instead be licensed under
   CC-BY-ND.

*** The package need not follow the GNU Coding Standards or the GNU
   Maintainers Guide, except for a few specific points as stated below.

*** The package must follow the rules in
   https://www.gnu.org/prep/standards/, node References.  This means it
   may not refer users to any nonfree software or nonfree
   documentation, except as stated there.  Leading users to run a
   program, and suggesting they run it, or depending on it to be
   installed, are forms of referring users to it.

*** Aside from packages obtained from GNU ELPA and NonGNU ELPA,
   a package may not run code that it has fetched over the internet.

   In particular, the package may install other packages in GNU ELPA and
   NonGNU ELPA, but not any other software.

   We will consider exceptions to that rule, but we will need to
   consider them carefully, to make sure that the practices are
   safe for Emacs users, not just in one package but when used in
   many packages.  Each time we approve such an exception, we will
   say so in comments in the package, with an explanation of our reasoning.

*** The package must deliver its full functionality and convenience on a
   completely free platform based on the GNU operating system (in
   practice, GNU/Linux), working exclusively with other free software.
   Otherwise, it would act as an inducement to install nonfree systems
   or other nonfree software, and that would work against our cause.

   However, as an exception it is ok for a package to provide, on some
   non-GNU operating systems, features that the rest of Emacs (plus GNU
   ELPA and NonGNU ELPA) already supports on GNU.

   This is a moral issue.  See https://www.gnu.org/prep/standards/,
   node System Portability.  The reason for this rule is that at no
   time, in no way, should a NonGNU ELPA package put users who defend
   their freedom at a disadvantage compared with those who surrender
   their freedom.

*** The package may communicate with a class of remote services, either
   using a standard interface or using an ad-hoc interface for each
   service, or a combination, *provided* that these services' jobs
   consist of either communication or lookup of published data.

   The package may not use remote services to do the user's own
   computational processing.  "Your own computational processing" means
   anything you could _in principle_ do in your own computers by
   installing and running suitable software, without communicating with
   any other computers.

*** A general Savannah rule about advertisements

   In general, you may not advertise anything commercial with material
   in the NonGNU ELPA package or this repository.  However, as
   exceptions, you can point people to commercial support offerings for
   the package, and you can mention fan items that you sell directly to
   the users.



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-15 05:14]:
> >> One good way to comply is the package I made for friend
> >> from Sweden:
> >>
> >> your hjälpsam Package Header Assistant
> >> https://hyperscope.link/3/7/7/3/0/Your-hjälpsam-Package-Header-Assistant-37730.html
> >
> > Hahaha :D
> >
> > "hjälpsam" = helpful
> 
> Very good!
> 
> Only this:
> 
> (defun package-header-ask-keywords ()
>   "Ask author for package keywords."
>   (let ((keywords '())
>         (keyword))
>     (while (string-match "[^[:blank:]]"
>                          (setq keyword
>                                (completing-read "Keywords: " (package-header-keywords) nil t)))
>       (push keyword keywords))
>     (when keywords
>       (mapconcat 'identity (sort keywords #'string<) " "))))
> 
> In the prompt string, maybe it is a good idea to mention how
> to quit? Type nothing just hit RET? Since/if every pack should
> have at least one keyword, the first PS could be
> 
>   Keyword: [TAB to complete]
> 
> (note the singular form)
> 
> after that it could be
> 
>   Keyword: [RET to quit]
> 
> Then, remove duplicates from the result, I say this because
> when I tried the software it took three times to figure out
> that was how it worked, at first I thought it didn't register,
> so when I finally quit it said
> 
>   Keywords: convenience convenience convenience

Thanks for suggestions, I have changed it now to following:

(defun package-header-ask-keywords ()
  "Ask author for package keywords."
  (let ((keywords '())
	(keyword))
    (while (string-match "[^[:blank:]]"
			 (setq keyword
			       (completing-read "Keywords (RET to quit): " (package-header-keywords) nil t)))
      (push keyword keywords))
    (delete-dups keywords)
    (when keywords
      (mapconcat 'identity (sort keywords #'string<) " "))))

And with double key "s p", updated the published information:
https://hyperscope.link/3/7/7/3/0/Your-hj%C3%A4lpsam-Package-Header-Assistant-37730.html



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Fwd: How do I go about debugging my Elisp code?

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

>> > CC BY-SA 4.0 is one-way compatible with the GNU GPL version 3: this
>> > means you may license your modified versions of CC BY-SA 4.0
>> > materials under GNU GPL version 3, but you may not relicense GPL 3
>> > licensed works under CC BY-SA 4.0.
>> 
>> Aren't they doing exactly the latter when allowing elisp code to be
>> posted?
>
> That question I don't get.
>
>> According to your argument, every elisp code is a modification of
>> emacs itself and therefore must have the same license (or at least
>> equivalent terms) as emacs.
>
> Yes. My understanding is that CC BY-SA 4.0 license is compatible to
> GPL 3+ and thus all contributions on Emacs StackExchange are
> compatible to Emacs license, thus fine in that regard.

You said one-way compatible above, i.e., it is ok for me to use CC BY-SA
4.0 code snippets from SO in my GPL3+ package but according to your
argument, when I post some elisp code on emacs.stackexchange.com, that
code is automatically GPL+ (because you say every elisp code is a
modification of emacs itself), yet they redistribute it as CC BY-SA 4.0
which would be an infringement.  Or is that not what one-way compatible
means?

Bye,
Tassilo

Re: Fwd: How do I go about debugging my Elisp code?

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2022-01-15 13:23]:
> You said one-way compatible above, i.e., it is ok for me to use CC BY-SA
> 4.0 code snippets from SO in my GPL3+ package but according to your
> argument, when I post some elisp code on emacs.stackexchange.com, that
> code is automatically GPL+ (because you say every elisp code is a
> modification of emacs itself), yet they redistribute it as CC BY-SA 4.0
> which would be an infringement.  Or is that not what one-way compatible
> means?

How I understand it CC BY-SA 4.0 is compatible to GNU GPL 3+, thus it
is compatible to Emacs' own license.

When you write Emacs Lisp code, you should license it so that license
is compatible to Emacs' license. 

I don't think that every Emacs Lisp code is modification of Emacs
itself. At the time when code becomes modification of Emacs in that
case the license of such code shall be compatible to Emacs license.

When is Emacs Lisp code not a modification of Emacs? In those cases
where Emacs Lisp is executed as a program on command line or in batch,
in those cases it may be not. When Guile is executing Emacs Lisp with
--language=elisp flag, then such code is not modifying Emacs.

When Emacs is run interactively and Emacs Lisp is loaded into running
Emacs editor, such code is modifying Emacs and thus shall be licensed
so that its license is compatible to Emacs license like GNU GPL 3+.



Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

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

Jean Louis wrote:

>> What's this NonGNU ELPA I keep hearing about lately?
>
> Maybe winter sleep took you too long.
>
> NonGNU Emacs Lisp Package Archive is the answer to issues
> otherwise not handled on MELPA, for example, this repository
> will include any kind of packages but not steer users to
> vague licensed packages or proprietary software.

Okay, sounds good, maybe I should put my stuff there?

Since maybe GNU ELPA has too high standards ... (for all
of it? depressing if so)

And MELPA - I actually tried - but couldn't figure out the
submit process and lost interest ...

Here are 9 Elisp packs (including 1 major mode for editing
code)

  https://dataswamp.org/~incal/emacs-packs/

I think we did this at least once before so the packs should
be ready formally, however if they aren't do tell and I'll be
happy to use the hjälpsam assistant :)

Please check them out and tell me how to submit them, if you
know how ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-17 06:49]:
> Here are 9 Elisp packs (including 1 major mode for editing
> code)
> 
>   https://dataswamp.org/~incal/emacs-packs/

Call it "packages" please.

> I think we did this at least once before so the packs should
> be ready formally, however if they aren't do tell and I'll be
> happy to use the hjälpsam assistant :)

Hjälpsam was written especially for you. 😛

> Please check them out and tell me how to submit them, if you
> know how ...

Of course, you write email to emacs-devel@gnu.org with the subject:
[ELPA] new package buc.el

and then make sure you submit papers to assign copyrights to FSF, they
will protect it hopefully, even if you become unavailable in some far
Asian country.

Now for review:

- xsel.el -- it does not have proper headers, you only mentioned
  license by its abbreviation, but that is not recommended. Sorry if I
  mixed something, though this is how it should look like.

Example header for xsel.el:
--------------------------

;;; xsel.el --- use the X clipboard -*- lexical-binding: t -*-

;; Copyright (C) 2021 by Emanuel Berg (incal) <moasenwood@zoho.eu>

;; Author: Emanuel Berg (incal) <moasenwood@zoho.eu>
;; Version: 2.3.7.
;; Package-Requires:
;; Keywords: unix
;; URL: https://dataswamp.org/~incal/emacs-packs/buc.el

;; This file is not part of GNU Emacs.

;; This program is free software: you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation, either version 3 of the
;; License, or (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program. If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;;; This gives you access to the X clipboard from a Linux
;;; VT/console/tty Emacs instance (or any Emacs, possibly).
;;; Set and/or Insert the X clipboard at point.
;;;
;;; DWIM: If there is a region, replace it with the
;;; X clipboard.
;;;
;;; Feature: Set the X clipboard programmatically in Elisp or
;;; set it interactively to the contents of the region (if
;;; there is one), otherwise set it to the most recent
;;; Emacs kill.
;;;
;;; Use $DISPLAY or ":0" with xsel(1x).
;;;

;;; Change Log:

;;; Code:



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

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

Jean Louis wrote:

>> I think we did this at least once before so the packs
>> should be ready formally, however if they aren't do tell
>> and I'll be happy to use the hjälpsam assistant :)
>
> Hjälpsam was written especially for you. 😛

Thanks a lot, love it :)

> Of course, you write email to emacs-devel@gnu.org with the
> subject: [ELPA] new package buc.el
>
> and then make sure you submit papers to assign copyrights to
> FSF, they will protect it hopefully, even if you become
> unavailable in some far Asian country.

Hm ... not sure it is that easy but if so, sure, they can have
whatever licence, I'm happy that you picked buc.el as the
example since it is maybe the most creative package and also
one that (A) has a ideology or philosophy but just as well
(B) is applicable and solves a practical situation _and_
(A) and (B) are in congruence with each other. Not easy to do!
And TBH I don't know if I managed a lot of times apart
from that. I don't remember why it is called "buc" tho,
"buffer cache" maybe or it refers to the US (German) writer
Charles "Buk" Bukowski ...

> ;; Copyright (C) 2021 by Emanuel Berg (incal) <moasenwood@zoho.eu>

Yeah, but you don't need that, just the licence, right?

> ;; Author: Emanuel Berg (incal) <moasenwood@zoho.eu>
> ;; Version: 2.3.7.

Yuk, a dot?

> ;; Package-Requires:
> ;; Change Log:

Waat, if the header isn't there that should imply nothing!

I can add a Change Log when there are changes, if they are big
but I don't think that'll happen. Besides should you really
hard-code that, isn't that what you have repositories, VCSs,
etc, for?

Really interesting and unusual/exotic history items I'd gladly
add tho but that won't happen, well, one can hope it will ;)

Nike's wings and pandora's box ...
https://www.youtube.com/watch?v=iqM9P4TdA7E

> ;; This file is not part of GNU Emacs.
>
> ;; This program is free software: you can redistribute it and/or
> ;; modify it under the terms of the GNU General Public License as
> ;; published by the Free Software Foundation, either version 3 of the
> ;; License, or (at your option) any later version.
> ;;
> ;; This program is distributed in the hope that it will be useful, but
> ;; WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> ;; General Public License for more details.
> ;;
> ;; You should have received a copy of the GNU General Public License
> ;; along with this program. If not, see <http://www.gnu.org/licenses/>.

Again is this an Emacs convention or is it mandatory for
the license?

If it is needed to put the code somewhere (anywhere), I'll be
happy to add it, of course, otherwise I think it is just bulky
and doesn't contribute anything interesting. My code should be
fit for a particular purpose! Still, it's OK to put it like
that, it doesn't change the quality of the code. Mere words ...

> ;;; Commentary [...]

Please read the documentation and see if it can be improved as
well, as I'm sure it can!

>> Here are 9 Elisp packs (including 1 major mode for editing
>> code)
>> 
>>   https://dataswamp.org/~incal/emacs-packs/
>
> Call it "packages" please.

It's just the directory ...

And long words like length, width, packages, directories are
much harder to spell/type than len, w, packs, dirs, so in
everything computers (i.e., what we are doing now is not
computers but humans) but with everything computers I think
short forms should be favored ("prev" is can also be aligned
with "next", but "previous" can't; "beg" is much shorter and
easier/faster to spell/type than beginning, and it can be
aligned with "end"; and so on).

Lisp is super-verbose as it is! Everything to make it shorter
and faster is good: str (not string), col (column), buf
(buffer), sjl (Super Jean Louis) ...

I'm not saying we should change `previous-line' to "prev-line"
but actually yes, if I implemented a Lisp dialect I'd be
`prev-line' (maybe `backward-char' would be `prev-char' for
consistency, it is also clearer, in that case tho I don't know
what gain calling it `back-char' would be, not increased
clarity anyway :)) - what one can do now is aliases, I guess,
with respect to that -

  (defalias 'prev-line #'previous-line)

but what should do even more is not do it like `defalias' has
it, namely

  (defalias SYMBOL DEFINITION &optional DOCSTRING)

it should be

  (defalias SYM DEF &optional DOCSTR)

IMO!

-- 
underground experts united
https://dataswamp.org/~incal

Re: Fwd: How do I go about debugging my Elisp code?

[Davin Pearson]

My code is obsolete if I can figure out how to
get the edebug online.  See another message
for my attempt to do this.  The subject of my other
message is: How do I get edebug online?

Thank you all for your help with this.

On Sun, 16 Jan 2022 at 00:33, Jean Louis <bugs@gnu.support> wrote:

> * Tassilo Horn <tsdh@gnu.org> [2022-01-15 13:23]:
> > You said one-way compatible above, i.e., it is ok for me to use CC BY-SA
> > 4.0 code snippets from SO in my GPL3+ package but according to your
> > argument, when I post some elisp code on emacs.stackexchange.com, that
> > code is automatically GPL+ (because you say every elisp code is a
> > modification of emacs itself), yet they redistribute it as CC BY-SA 4.0
> > which would be an infringement.  Or is that not what one-way compatible
> > means?
>
> How I understand it CC BY-SA 4.0 is compatible to GNU GPL 3+, thus it
> is compatible to Emacs' own license.
>
> When you write Emacs Lisp code, you should license it so that license
> is compatible to Emacs' license.
>
> I don't think that every Emacs Lisp code is modification of Emacs
> itself. At the time when code becomes modification of Emacs in that
> case the license of such code shall be compatible to Emacs license.
>
> When is Emacs Lisp code not a modification of Emacs? In those cases
> where Emacs Lisp is executed as a program on command line or in batch,
> in those cases it may be not. When Guile is executing Emacs Lisp with
> --language=elisp flag, then such code is not modifying Emacs.
>
> When Emacs is run interactively and Emacs Lisp is loaded into running
> Emacs editor, such code is modifying Emacs and thus shall be licensed
> so that its license is compatible to Emacs license like GNU GPL 3+.
>
>
>
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>

Re: NonGNU ELPA

[Stefan Monnier via Users list for the GNU Emacs text editor]

> ;;; This gives you access to the X clipboard from a Linux
> ;;; VT/console/tty Emacs instance (or any Emacs, possibly).
> ;;; Set and/or Insert the X clipboard at point.

ELisp convention is to use ";;;" (and more) for section headers.
So please use just ";;" for normal comments.

> ;;; DWIM: If there is a region, replace it with the
> ;;; X clipboard.
> ;;;
> ;;; Feature: Set the X clipboard programmatically in Elisp or
> ;;; set it interactively to the contents of the region (if
> ;;; there is one), otherwise set it to the most recent
> ;;; Emacs kill.
> ;;;
> ;;; Use $DISPLAY or ":0" with xsel(1x).

Sounds similar to GNU ELPA's `xclip.el`.
Any chance the two could be merged?


        Stefan

Re: NonGNU ELPA

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

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> ;;; DWIM: If there is a region, replace it with the
>> ;;; X clipboard.
>> ;;;
>> ;;; Feature: Set the X clipboard programmatically in Elisp or
>> ;;; set it interactively to the contents of the region (if
>> ;;; there is one), otherwise set it to the most recent
>> ;;; Emacs kill.
>> ;;;
>> ;;; Use $DISPLAY or ":0" with xsel(1x).
>
> Sounds similar to GNU ELPA's `xclip.el`.
> Any chance the two could be merged?

Don't know but if you say so ... so, okay?

Don't know if/how much the base shell tools differ either,
xclip(1) and xsel(1x), maybe the Elisp solutions are
interface-exchangeable even.

$ sudo aptitude more xclip xsel
i   xclip - command line interface to X selections
i   xsel  - command-line tool to access X clipboard a

$ xclip -version
  xclip version 0.13
  Copyright (C) 2001-2008 Kim Saunders et al.
  Distributed under the terms of the GNU GPL

$ xsel --version
  xsel version 1.2.0 by Conrad Parker <conrad@vergenet.net>

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

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

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

> ELisp convention is to use ";;;" (and more) for section
> headers. So please use just ";;" for normal comments.

Yeah ... correct.

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> Sounds similar to GNU ELPA's `xclip.el`.
>> Any chance the two could be merged?
>
> Don't know but if you say so ... so, okay?

Obviously you won't know before you actually look at it.

> Don't know if/how much the base shell tools differ either,
> xclip(1) and xsel(1x), maybe the Elisp solutions are
> interface-exchangeable even.

I strongly recommend looking at `xclip.el` before going any further,
because opinions derived just from the name of a package tend to be
rather ... brittle.


        Stefan

Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-18 03:11]:
> > ;; Copyright (C) 2021 by Emanuel Berg (incal) <moasenwood@zoho.eu>
> 
> Yeah, but you don't need that, just the licence, right?

You need it. It should be known who has copyrights assigned, who is
author, and by which license it is published.

> I can add a Change Log when there are changes, if they are big
> but I don't think that'll happen. Besides should you really
> hard-code that, isn't that what you have repositories, VCSs,
> etc, for?

From: (info "(elisp) Library Headers")

‘;;; Change Log:’
     This begins an optional log of changes to the file over time.
     Don’t put too much information in this section—it is better to keep
     the detailed logs in a version control system (as Emacs does) or in
     a separate ‘ChangeLog’ file.  ‘History’ is an alternative to
     ‘Change Log’.

> > ;; This file is not part of GNU Emacs.
> >
> > ;; This program is free software: you can redistribute it and/or
> > ;; modify it under the terms of the GNU General Public License as
> > ;; published by the Free Software Foundation, either version 3 of the
> > ;; License, or (at your option) any later version.
> > ;;
> > ;; This program is distributed in the hope that it will be useful, but
> > ;; WITHOUT ANY WARRANTY; without even the implied warranty of
> > ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > ;; General Public License for more details.
> > ;;
> > ;; You should have received a copy of the GNU General Public License
> > ;; along with this program. If not, see <http://www.gnu.org/licenses/>.
> 
> Again is this an Emacs convention or is it mandatory for
> the license?

"This file is part or not part of GNU Emacs" is convention.

C-h C-c shall tell you how to apply the license.

            How to Apply These Terms to Your New Programs

  If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.

  To do so, attach the following notices to the program.  It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.

    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <https://www.gnu.org/licenses/>.

Also add information on how to contact you by electronic and paper mail.

  If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:

    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License.  Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".

  You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<https://www.gnu.org/licenses/>.

That above does not tell you must do it that way. But think about it,
you did not put copy of the license with the file. Did you? 

So I get the file and give it to somebody else, that person, with the
header you have where license reference and information about no
warranty is missing -- could eventually sue and cause troubles because
license was not known and not clearly referenced. A tag like GPL3+ is
simply not enough. Don't assume people who receive the program are
supposed to know what the tag "GPL3+" means. You cannot even assume
that all people have Internet available like you have it. Thus license
should be given along the program, see:

  4. Conveying Verbatim Copies.

  You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.

  You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.

Emacs is shipped with the license built-in. Rigth? Tag alone is not
enough. 

What if you find a single file in a whole program. Maybe license was
included in the package, but now single file goes individually
somewhere else. In that case a reference to license would be lost
unless it is in the headers.

Best way to foster free software with legal notices is already laid
out in the GNU GPL 3+ and previous versions.

> If it is needed to put the code somewhere (anywhere), I'll be
> happy to add it, of course, otherwise I think it is just bulky
> and doesn't contribute anything interesting. My code should be
> fit for a particular purpose! Still, it's OK to put it like
> that, it doesn't change the quality of the code. Mere words ...

Legality is important. If there is claim to be "fit for particular
purpose" could bring you as author in liabilities. 


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA (was: Re: Fwd: How do I go about debugging my Elisp code?)

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

Jean Louis wrote:

> who is author, and by which license it is published[, what
> year ...]

It already contains all that data:

;;; Author: Emanuel Berg (incal) <moasenwood@zoho.eu>
;;; Created: 2021-05-04
;;; [...]
;;; License: GPL3+

>> I can add a Change Log when there are changes, if they are
>> big but I don't think that'll happen. Besides should you
>> really hard-code that, isn't that what you have
>> repositories, VCSs, etc, for?
>
> From: (info "(elisp) Library Headers")
>
> ‘;;; Change Log:’
>      This begins an optional log of changes to the file over
>      time. Don’t put too much information in this section—it
>      is better to keep the detailed logs in a version
>      control system (as Emacs does) or in a separate
>      ‘ChangeLog’ file. ‘History’ is an alternative to
>      ‘Change Log’.

Indeed, OK so that can be dumped, good. Actually it shouldn't
be encouraged to use. Move content in current files into
a HISTORY file ...

Okay, so, well, no one read the documentation but apart from
that it is only the ";;;" (header) vs ";;" (whole-line
comment) I should fix then ... sweet.


https://dataswamp.org/~incal/bot/scripts/hist
https://dataswamp.org/~incal/COMP-HIST

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

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

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> Don't know if/how much the base shell tools differ either,
>> xclip(1) and xsel(1x), maybe the Elisp solutions are
>> interface-exchangeable even.
>
> I strongly recommend looking at `xclip.el` before going any
> further, because opinions derived just from the name of
> a package tend to be rather ... brittle.

:)

But this is an interesting situation. There are two Linux
tools. Should there be one Elisp package that works with
either, or should there be one for each?

Yeah, I'll look into it ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Stefan Monnier via Users list for the GNU Emacs text editor]

Emanuel Berg via Users list for the GNU Emacs text editor [2022-01-21 22:32:42] wrote:
> Stefan Monnier via Users list for the GNU Emacs text editor wrote:
>> I strongly recommend looking at `xclip.el` before going any
>> further, because opinions derived just from the name of
>> a package tend to be rather ... brittle.
> :)
> But this is an interesting situation. There are two Linux
> tools. Should there be one Elisp package that works with
> either, or should there be one for each?

It's even more twisted than that: according to
http://elpa.gnu.org/packages/xclip.html, `xclip.el` already supports
four of those two GNU/Linux tools.


        Stefan

Re: NonGNU ELPA

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

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>>> I strongly recommend looking at `xclip.el` before going any
>>> further, because opinions derived just from the name of
>>> a package tend to be rather ... brittle.
>>
>> :)
>>
>> But this is an interesting situation. There are two Linux
>> tools. Should there be one Elisp package that works with
>> either, or should there be one for each?
>
> It's even more twisted than that: according to
> http://elpa.gnu.org/packages/xclip.html, `xclip.el` already
> supports four of those two GNU/Linux tools.

Hahaha :D

Now I really must check it out ...

But - a distant bell rings - I heard somewhere that these not
exactly hackish workarounds - or actually they are
clever hacks! - I heard they were not needed since Emacs
provided this out of the box. I remember I tested, but it
didn't work.

Maybe that is because of the configuration option
--with-x-toolkit=no (actually I don't know when I started with
that, I remember the emacs-nox package ... - that's "no X" -
but now comes yet another twist, I, who configure/compile like
that since I just use Emacs in a Linux VT/tty/console with no
need for that it would seem, I use that stuff (xsel.el) every
day.

Literally! It isn't really necessary for life/work, the 19/20
use case is to watch some video material I find on the net or
someone tells me to check out so I get a sneak peak with mp3
before I decide to download it or not.

So maybe I and people with similar "habits" should compile
with the X stuff?

But if everyone does, what is the deal with xclip.el and
xsel.el ? Can everyone stop using them if everyone just
compiled with the X stuff?

Here, no sneak peak, _instant download_. Gigi Hadid and
progressive trance (progressive trance = repeats the same
pattern also in long loops, but all the while force and
intensity is increased. can you tell there is something fishy
going on?)

  https://dataswamp.org/~incal/vidz/fighting-fit-new-school.mp4
  
-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

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

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>>> I strongly recommend looking at `xclip.el` before going
>>> any further, because opinions derived just from the name
>>> of a package tend to be rather ... brittle.
>>
>> :)
>>
>> But this is an interesting situation. There are two Linux
>> tools. Should there be one Elisp package that works with
>> either, or should there be one for each?
>
> It's even more twisted than that: according to
> http://elpa.gnu.org/packages/xclip.html, `xclip.el` already
> supports four of those two GNU/Linux tools.

But ... the correct way is to merge, right, because the
solution should be in terms of the problem, not what
technology happens to make it possible?

The more the merrier! Emacs, Linux (GNU/Linux) and zsh, all
maximalist projects, like that song. I wouldn't go so far as
to say she is the minimalized interface - rather a power
player in her on right.

So bring everything in and have the interface sort it out ...

"What you once feared, now makes you free"

https://dataswamp.org/~incal/vidz/fighting-fit-new-school.mp4

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

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

> The more the merrier! Emacs, Linux (GNU/Linux) and zsh, all
> maximalist projects, like that song. I wouldn't go so far as
> to say she is the minimalized interface - rather a power
> player in her on right.

    <incal> ,, hist Emacs, GNU Emacs, XEmacs, zsh, Linux
    
      <sth> Emacs 1976 TECO EMACS Editor MACroS, keyboard
            shortcuts and Lisp. MIT
            
      <sth> GNU Emacs 1984 GNU Emacs. The first, and still
            poster project, of GNU
            
      <sth> XEmacs 1991 fork/split derived from GNU Emacs
            version 18
      
      <sth> zsh 1990 shell with many features
      
      <sth> Linux 1991 Monolithic Unix by enthusiasts/zealots

Should add XEmacs is finito ...

https://dataswamp.org/~incal/#bot

  B/W (1986):
  https://dataswamp.org/~incal/pimgs/dark-castle.png

Runs with the Mac Plus x86 Linux emulator.

Keep it real ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

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

The situation doesn't make any sense, I also use it from
Emacs-w3m where I save the URL of a YouTube song/music video
in Emacs-w3m [1] then I download it with a zsh function [2]
but, if we increase our altitude and look down on what then
happens, the Emacs-w3m stuff happens in the Emacs instance in
/dev/tty1 and the zsh stuff happens in tmux on top of
/dev/tty2 ... and the bridge is xsel.el [3] but X isn't even
visited or involved.

(Except it doesn't work if it isn't on.)

I can even play it in the console with mpv [4]

That song is "The Climb" by No Doubt BTW ... [5]

Which I proudly quote here [6]

If you think I'm running out of footnotes this way,
think again! Hey, it's FOSS. The plethora, annoying as it may,
is actually the strength, right?

:)

[1] https://dataswamp.org/~incal/emacs-init/w3m/w3m-url.el
    (hm ... seemingly strange that isn't this file:
     https://dataswamp.org/~incal/emacs-init/w3m/w3m-download.el )
[2] https://dataswamp.org/~incal/conf/.zsh/dl
[3] https://dataswamp.org/~incal/emacs-init/xsel.el
[4] https://dataswamp.org/~incal/#mpv
[5] https://www.youtube.com/watch?v=G0E1khrhE3c
[6] https://dataswamp.org/~incal/blog/tree-house/tree-house-rooftop.html

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Po Lu]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:


> But - a distant bell rings - I heard somewhere that these not
> exactly hackish workarounds - or actually they are
> clever hacks! - I heard they were not needed since Emacs
> provided this out of the box. I remember I tested, but it
> didn't work.
>
> Maybe that is because of the configuration option
> --with-x-toolkit=no (actually I don't know when I started with
> that, I remember the emacs-nox package ... - that's "no X" -
> but now comes yet another twist, I, who configure/compile like
> that since I just use Emacs in a Linux VT/tty/console with no
> need for that it would seem, I use that stuff (xsel.el) every
> day.
>
> Literally! It isn't really necessary for life/work, the 19/20
> use case is to watch some video material I find on the net or
> someone tells me to check out so I get a sneak peak with mp3
> before I decide to download it or not.
>
> So maybe I and people with similar "habits" should compile
> with the X stuff?
>
> But if everyone does, what is the deal with xclip.el and
> xsel.el ? Can everyone stop using them if everyone just
> compiled with the X stuff?
>
> Here, no sneak peak, _instant download_. Gigi Hadid and
> progressive trance (progressive trance = repeats the same
> pattern also in long loops, but all the while force and
> intensity is increased. can you tell there is something fishy
> going on?)

I don't really understand what you're saying here, but introducing a
compile-time option that lets Emacs open an X display connection to
access selections without being able to create frames would be extremely
pointless, since if you can access selections, you already have
everything you need to create frames.

So the clean solution for accessing X selections is either to run Emacs
under X, or to use something like xclip.el.

Re: NonGNU ELPA

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

Po Lu wrote:

> I don't really understand what you're saying here

1) Think
2) Ask a friend
3) Ask the teacher

> but introducing a compile-time option that lets Emacs open
> an X display connection to access selections without being
> able to create frames would be extremely pointless, since if
> you can access selections, you already have everything you
> need to create frames.

Frames? You mean like web pages had in the 90s?

> So the clean solution for accessing X selections is either
> to run Emacs under X, or to use something like xclip.el.

This must be the cleanest, compile Emacs without X, use
xsel.el [1] to communicate from Emacs to X, and from X to
Emacs (it is a theoretical possibility not observed in the
wild), _and_ from Emacs to the other ttys - without passing X,
which still has to run for it to work.

Remember the SEGA slogan - "Beat us. If you can"

Same then. As now.

BTW xclip.el was written by Leo Liu ... I'll CC him.
Probably a cool guy. Developer.

[1] https://dataswamp.org/~incal/emacs-init/xsel.el

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Po Lu]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Frames? You mean like web pages had in the 90s?

See the node "Frames and Graphical Displays" in the Emacs manual.

> This must be the cleanest, compile Emacs without X, use
> xsel.el [1] to communicate from Emacs to X, and from X to
> Emacs (it is a theoretical possibility not observed in the
> wild), _and_ from Emacs to the other ttys - without passing X,
> which still has to run for it to work.

If you're running Emacs under X (which most people should be doing
anyway), then the best solution would certainly to use the built-in X
selection support.

xsel.el is only clean if you're running Emacs without X for whatever
reason.

Re: NonGNU ELPA

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

Po Lu wrote:

>> This must be the cleanest, compile Emacs without X, use
>> xsel.el [1] to communicate from Emacs to X, and from X to
>> Emacs (it is a theoretical possibility not observed in the
>> wild), _and_ from Emacs to the other ttys - without passing
>> X, which still has to run for it to work.
>
> If you're running Emacs under X (which most people should be
> doing anyway), then the best solution would certainly to use
> the built-in X selection support.

1) Read
2) Think
3) ...

> xsel.el is only clean if you're running Emacs without X for
> whatever reason.

Recommended move:

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

Alicia Silverstone.

That's right! Positive thinking, man ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Po Lu]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> 1) Read
> 2) Think
> 3) ...

[...]

> Recommended move:
>
>   https://en.wikipedia.org/wiki/Clueless
>
> Alicia Silverstone.
>
> That's right! Positive thinking, man ...

I have no idea what you are trying to get across.

Re: NonGNU ELPA

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-22 08:41]:
> > but introducing a compile-time option that lets Emacs open
> > an X display connection to access selections without being
> > able to create frames would be extremely pointless, since if
> > you can access selections, you already have everything you
> > need to create frames.
> 
> Frames? You mean like web pages had in the 90s?

Not those frames... 😅


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA

[Jean Louis]

* Po Lu <luangruo@yahoo.com> [2022-01-22 09:34]:
> If you're running Emacs under X (which most people should be doing
> anyway), then the best solution would certainly to use the built-in X
> selection support.

I have set Emacs to duplicate any selection so that I can re-use it
from terminal to Emacs and vice versa. It works well, I cannot be
sure, but it may be this option below:

Hide Select Enable Clipboard: Boolean: Toggle  on (non-nil)
    State : STANDARD.
   Non-nil means cutting and pasting uses the clipboard. Hide
   This can be in addition to, but in preference to, the primary selection,
   if applicable (i.e. under X11).
Groups: Killing



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA

[Po Lu]

Jean Louis <bugs@gnu.support> writes:

> I have set Emacs to duplicate any selection so that I can re-use it
> from terminal to Emacs and vice versa. It works well, I cannot be
> sure, but it may be this option below:
>
> Hide Select Enable Clipboard: Boolean: Toggle  on (non-nil)
>     State : STANDARD.
>    Non-nil means cutting and pasting uses the clipboard. Hide
>    This can be in addition to, but in preference to, the primary selection,
>    if applicable (i.e. under X11).
> Groups: Killing

That has been enabled by default for a while now.  Basically it resolves
the problem where Emacs was the last program to not adopt the "standard"
interpretation of how the various X selections should be used.

Re: NonGNU ELPA

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

Jean Louis wrote:

>>> but introducing a compile-time option that lets Emacs open
>>> an X display connection to access selections without being
>>> able to create frames would be extremely pointless, since
>>> if you can access selections, you already have everything
>>> you need to create frames.
>> 
>> Frames? You mean like web pages had in the 90s?
>
> Not those frames... 😅

The diamond frame?

  https://dataswamp.org/~incal/work-photos/fixie.jpg

-- 
underground experts united
https://dataswamp.org/~incal

Re: NonGNU ELPA

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-01-22 16:49]:
> Jean Louis wrote:
> 
> >>> but introducing a compile-time option that lets Emacs open
> >>> an X display connection to access selections without being
> >>> able to create frames would be extremely pointless, since
> >>> if you can access selections, you already have everything
> >>> you need to create frames.
> >> 
> >> Frames? You mean like web pages had in the 90s?
> >
> > Not those frames... 😅
> 
> The diamond frame?
> 
>   https://dataswamp.org/~incal/work-photos/fixie.jpg

Heh, that is a good function.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: NonGNU ELPA

[Stefan Monnier via Users list for the GNU Emacs text editor]

> So the clean solution for accessing X selections is either to run Emacs
> under X, or to use something like xclip.el.

Indeed `xclip.el` already covers the case where you want to use of
Emacs's own X code to access the X selection when Emacs itself is "only"
running in a tty (i.e. `xclip.el` internally creates a hidden frame on
the X display).

The question w.r.t `xsel.el` is whether the functionality it offers via
`xsel` is different from that offered by `xclip.el` (eithef via `xsel`
or via other means), and if so whether the two shoud be combined/merged
or kept separate (like `gpastel.el` is currently kept separate).


        Stefan

Re: NonGNU ELPA

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

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

> The question w.r.t `xsel.el` is whether the functionality it
> offers via `xsel` is different from that offered by
> `xclip.el` (eithef via `xsel` or via other means), and if so
> whether the two shoud be combined/merged or kept separate
> (like `gpastel.el` is currently kept separate).

xsel.el is only 85 lines (including the bulk of standard
documentation) so please find out ...

It is a getter, a setter, two Emacs-specific applications and
a shorthand.

Very basic one would think?

;;; xsel.el --- use the X clipboard -*- lexical-binding: t -*-
;;;
;;; Commentary:
;;;
;;; Author: Emanuel Berg (incal) <moasenwood@zoho.eu>
;;; Created: 2021-05-04
;;; Keywords: unix
;;; License: GPL3+
;;; URL: https://dataswamp.org/~incal/emacs-init/xsel.el
;;; Version: 2.3.7
;;;
;;; This gives you access to the X clipboard from a Linux
;;; VT/console/tty Emacs instance (or any Emacs, possibly).
;;; Set and/or Insert the X clipboard at point.
;;;
;;; DWIM: If there is a region, replace it with the
;;; X clipboard.
;;;
;;; Feature: Set the X clipboard programmatically in Elisp or
;;; set it interactively to the contents of the region (if
;;; there is one), otherwise set it to the most recent
;;; Emacs kill.
;;;
;;; Use $DISPLAY or ":0" with xsel(1x).
;;;
;;; Code:

(let ((xsel-x-display (or (getenv "DISPLAY") ":0")))
  (defun insert-x-clipboard ()
    "Insert the X clipboard at point using xsel(1x).
If there is a region it is overwritten."
    (interactive)
    (when (use-region-p)
      (delete-region (region-beginning) (region-end)) )
    (shell-command
     (format "xsel --display \"%s\" --clipboard -o" xsel-x-display)
     1) ; insert in current buffer
    (goto-char (mark)) )
  (declare-function insert-x-clipboard nil)

  (defun set-x-clipboard (str)
    "Set the X clipboard to STR. When used interactively, STR
is either what is in the region, if available, if not the most
recent Emacs kill is used."
    (interactive
     (list (if (use-region-p)
               (buffer-substring-no-properties (region-beginning) (region-end))
             (encode-coding-string (current-kill 0 t) 'utf-8-unix) )))
    (shell-command
     (format "echo -n %s | xsel --display %s -b -i"
             (shell-quote-argument str)
             xsel-x-display) ))
  (declare-function set-x-clipboard nil) )

(defun x-copy (&optional beg end)
  "Copy the buffer text from BEG to END to the X clipboard.
Unless optional arguments are provided the whole buffer text is used."
  (interactive (when (use-region-p)
                 (list (region-beginning) (region-end)) ))
  (let ((b (or beg (point-min)))
        (e (or end (point-max))) )
    (set-x-clipboard (buffer-substring b e) )))

(defun x-copy-symbol (sym)
  "Copy the value of SYM to the X clipboard."
  (interactive "S Symbol: ")
  (let*((val (symbol-value sym))
        (str (format "%s" val)) )
    (set-x-clipboard str) ))
;; (progn (x-copy-symbol 'fill-column)         (insert-x-clipboard))
;; (progn (call-interactively #'x-copy-symbol) (insert-x-clipboard))

(defun x-clipboard-dwim ()
  "If the region is active, set the X clipboard, if not, insert it."
  (interactive)
  (call-interactively
   (if (use-region-p)
       #'set-x-clipboard
     #'insert-x-clipboard) ))

(defalias 'x  #'x-clipboard-dwim)
(defalias 'xo #'insert-x-clipboard)

(provide 'xsel)
;;; xsel.el ends here

-- 
underground experts united
https://dataswamp.org/~incal