* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
@ 2022-09-30 16:59 Markus Triska
2022-10-01 12:56 ` Lars Ingebrigtsen
` (5 more replies)
0 siblings, 6 replies; 35+ messages in thread
From: Markus Triska @ 2022-09-30 16:59 UTC (permalink / raw)
To: 58196
ediprolog 2.2 is now available from:
https://www.metalevel.at/ediprolog/ediprolog.el
New in this version:
* handle answers of recent Scryer Prolog versions
* faithful processing of multiline queries when using Scryer Prolog
* improved compatibility with older Emacs versions
Project page:
https://www.metalevel.at/ediprolog/
Video demonstration:
https://www.metalevel.at/prolog/videos/ediprolog
For completeness, I also include a copy of the source code below.
Could you please upload the new release to ELPA?
Thank you a lot!
Markus
;;; ediprolog.el --- Emacs Does Interactive Prolog
;; Copyright (C) 2006-2022 Markus Triska
;; Author: Markus Triska <triska@metalevel.at>
;; Keywords: languages, processes
;; Homepage: https://www.metalevel.at/ediprolog/
;; This file 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, or (at your option)
;; any later version.
;; This file 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 <http://www.gnu.org/licenses/>.
;;; Commentary:
;; These definitions let you interact with Prolog in all buffers.
;; You can consult Prolog programs and evaluate embedded queries.
;; Installation
;; ============
;;
;; Copy ediprolog.el to your load-path and add to your .emacs:
;;
;; (require 'ediprolog)
;; (global-set-key [f10] 'ediprolog-dwim)
;;
;; Restart Emacs and customize ediprolog with
;;
;; M-x customize-group RET ediprolog RET
;;
;; The two most important configuration options are:
;;
;; - `ediprolog-system', either 'scryer (default) or 'swi
;; - `ediprolog-program', the path of the Prolog executable.
;; Usage
;; =====
;;
;; The central function is `ediprolog-dwim' (Do What I Mean), which is
;; bound to F10 by the snippet above. Depending on the content at
;; point, `ediprolog-dwim' does the "appropriate" thing: If point is
;; on a query, F10 sends the query to a Prolog process, and you
;; interact with the process in the current buffer as on a terminal.
;; Queries start with "?-" or ":-", possibly preceded by "%" and
;; whitespace. An example of a query is (without leading ";;"):
;;
;; %?- member(X, "abc").
;;
;; If you press F10 when point is on that query, you get:
;;
;; %?- member(X, "abc").
;; %@ X = a
;; %@ ; X = b
;; %@ ; X = c
;; %@ ; false.
;;
;; When waiting for output of the Prolog process, you can press C-g to
;; unblock Emacs and continue with other work. To resume interaction
;; with the Prolog process, use M-x ediprolog-toplevel RET.
;; If you press F10 when point is *not* on a query, the buffer content
;; is consulted in the Prolog process, and point is moved to the first
;; error (if any). In transient mark mode, if the region is active,
;; only the text in the region is consulted.
;; For convenience, the most recent interactions with the Prolog
;; process are logged in the buffer "*ediprolog-history*".
;; Use M-x ediprolog-localize RET to make any Prolog process started
;; in the current buffer buffer-local. This way, you can run distinct
;; processes simultaneously. Revert with M-x ediprolog-unlocalize RET.
;; `ediprolog-dwim' with prefix arguments has special meanings:
;;
;; C-0 F10 kill Prolog process
;; C-1 F10 always consult buffer (even when point is on a query)
;; C-2 F10 always consult buffer, using a new process
;; C-7 F10 equivalent to `ediprolog-toplevel'
;; C-u F10 first consult buffer, then evaluate query (if any)
;; C-u C-u F10 like C-u F10, with a new process
;; Tested with Scryer Prolog 0.8.119 and SWI-Prolog 8.1.24,
;; using Emacs versions 26.1 and 27.0.50.
;;; Code:
(defconst ediprolog-version "2.2")
(defgroup ediprolog nil
"Transparent interaction with Prolog."
:group 'languages
:group 'processes)
(defcustom ediprolog-system 'scryer
"Prolog system that is used for interaction."
:group 'ediprolog
:type '(choice (const :tag "Scryer Prolog" :value scryer)
(const :tag "SWI Prolog" :value swi)))
(defcustom ediprolog-program
(or
(executable-find "scryer-prolog")
(executable-find "swipl")
"scryer-prolog")
"Program name of the Prolog executable."
:group 'ediprolog
:type 'string)
(defcustom ediprolog-program-switches nil
"List of switches passed to the Prolog process. Example:
'(\"-G128M\" \"-O\")"
:group 'ediprolog
:type '(repeat string))
(defcustom ediprolog-prefix "%@ "
"String to prepend when inserting output from the Prolog
process into the buffer."
:group 'ediprolog
:type 'string)
(defcustom ediprolog-max-history 80000
"Maximal size of history buffers storing recent interactions, or
nil to never truncate the history."
:group 'ediprolog
:type 'sexp)
(defvar ediprolog-process nil "A Prolog process.")
(defvar ediprolog-temp-buffer nil
"Buffer that temporarily saves process output ")
(defvar ediprolog-seen-prompt nil
"Whether a prompt was (recently) emitted by the Prolog process.")
(defvar ediprolog-read-term nil
"Whether the Prolog process waits for the user to enter a term.")
(defvar ediprolog-indent-prefix ""
"Any whitespace occurring before the most recently executed query.")
(defvar ediprolog-temp-file nil
"File name of a temporary file used for consulting the buffer.")
(defvar ediprolog-consult-buffer "*ediprolog-consult*"
"Buffer used to display consult output.")
(defvar ediprolog-consult-window nil
"Window used to show consult output.")
(defvar ediprolog-history-buffer nil
"Buffer that stores recent interactions.")
(defvar ediprolog-interrupted nil
"True iff waiting for the previous query was interrupted with C-g.")
(defun ediprolog-prompt ()
"Prompt used in the Prolog session."
(cond ((eq ediprolog-system 'swi) "?ediprolog- ")
(t "?- ")))
(defmacro ediprolog-wait-for-prompt-after (&rest forms)
"Evaluate FORMS and wait for prompt."
`(progn
(setq ediprolog-seen-prompt nil)
(ediprolog-ensure-buffer "temp")
(with-current-buffer ediprolog-temp-buffer
(let (buffer-read-only)
(erase-buffer)))
;; execute forms with default-directory etc. from invocation buffer
,@forms
(while (not ediprolog-seen-prompt)
;; Wait for output/sentinel and update consult window, if any.
;; As `accept-process-output' does not run the sentinel in
;; Emacs <= 23.1, we use `sit-for' to do both. However,
;; `sit-for' returns immediately if keyboard input is
;; available, so we must discard input.
(discard-input)
(sit-for 0.1))))
(defmacro ediprolog-remember-interruption (form)
"Set `ediprolog-interrupted' if evaluation of FORM was interrupted."
`(condition-case nil
,form
(quit (setq ediprolog-interrupted t))))
;; Only the sentinel can reliably detect if no more output follows -
;; even if process-status is 'exit, further output can still follow.
(defun ediprolog-sentinel (proc str)
(when (buffer-live-p (process-buffer proc))
(with-current-buffer (process-buffer proc)
(let ((status (with-temp-buffer
(insert str)
(while (search-backward "\n" nil t)
(replace-match ""))
(buffer-string))))
(ediprolog-log
(format "%s: %s.\n"
(substring (current-time-string) 4 -5) status) "green" t))
(when (string-match "^\\(?:finished\n\\|exited abnormally\\|killed\n\\)"
str)
(setq ediprolog-seen-prompt t)))))
(defun ediprolog-ensure-buffer (name)
(let ((str (format "*ediprolog-%s*" name))
(var (intern (format "ediprolog-%s-buffer" name))))
(unless (buffer-live-p (symbol-value var))
(set var (generate-new-buffer str))
(with-current-buffer (symbol-value var)
(buffer-disable-undo)
(setq buffer-read-only t)))))
(defun ediprolog-log (str &optional col nl)
(ediprolog-ensure-buffer "history")
(with-current-buffer ediprolog-history-buffer
(let (buffer-read-only)
(goto-char (point-max))
(let ((s (format "%s%s" (if (and nl (not (bolp))) "\n" "") str)))
(insert (if col (propertize s 'face `(:background ,col)) s)))
(let ((size (- (point-max) (point-min))))
(when (and ediprolog-max-history
(> size ediprolog-max-history))
;; delete older half of the (possibly narrowed) history
(delete-region (point-min) (+ (point-min) (/ size 2))))))))
(defun ediprolog-run-prolog ()
"Start a Prolog process."
(let ((args (cons ediprolog-program ediprolog-program-switches)))
(ediprolog-log (format "%s: starting: %S\n"
(substring (current-time-string) 4 -5) args)
"green" t)
(condition-case nil
(ediprolog-wait-for-prompt-after
(setq ediprolog-process
(apply #'start-file-process "ediprolog" (current-buffer) args))
(set-process-sentinel ediprolog-process 'ediprolog-sentinel)
(set-process-filter ediprolog-process
'ediprolog-wait-for-prompt-filter)
(when (eq ediprolog-system 'swi)
(ediprolog-send-string
(format "set_prolog_flag(color_term, false), \
set_prolog_flag(toplevel_prompt, '%s').\n" (ediprolog-prompt)))))
((error quit)
(ediprolog-log "No prompt found." "red" t)
(error "No prompt from: %s" ediprolog-program)))))
(defun ediprolog-kill-prolog ()
"Kill the Prolog process and run the process sentinel."
(when (ediprolog-running)
(delete-process ediprolog-process)))
(defun ediprolog-show-consult-output (str)
(with-current-buffer (get-buffer-create ediprolog-consult-buffer)
(setq buffer-read-only t)
(let (buffer-read-only)
(erase-buffer)
(insert str)
(goto-char (point-min))
;; remove normal consult status lines, which start with "%"
(while (re-search-forward "^[\t ]*%.*\n" nil t)
(delete-region (match-beginning 0) (match-end 0))))
(setq str (buffer-string)))
;; show consult output in a separate window unless it is a prefix of
;; success (i.e., consulted without errors), or still an incomplete
;; line that starts with a comment character
(unless (or (string-match "^[\t ]*\\(?:%.*\\)?\\'" str)
(string-prefix-p str "true.")
;; newer versions of Scryer Prolog prepend 3 spaces to "true."
(string-prefix-p str " true."))
(setq ediprolog-consult-window (display-buffer ediprolog-consult-buffer))
(set-window-dedicated-p ediprolog-consult-window t)
(fit-window-to-buffer ediprolog-consult-window (/ (frame-height) 2))))
(defun ediprolog-consult-filter (proc str)
"Filter used when consulting a file, showing consult output."
(with-current-buffer (ediprolog-temp-buffer proc)
(goto-char (point-max))
(let (buffer-read-only)
(insert str))
(with-current-buffer (process-buffer proc)
(ediprolog-log str))
(when (re-search-backward
(format "^%s" (regexp-quote (ediprolog-prompt))) nil t)
(with-current-buffer (process-buffer proc)
(setq ediprolog-seen-prompt t)))
(skip-chars-backward "\n")
(ediprolog-show-consult-output (buffer-substring (point-min) (point)))))
(defun ediprolog-wait-for-prompt-filter (proc str)
"Filter that only waits until prompt appears."
(with-current-buffer (ediprolog-temp-buffer proc)
(goto-char (point-max))
(let (buffer-read-only)
(insert str))
(with-current-buffer (process-buffer proc)
(ediprolog-log str))
(when (re-search-backward
(format "^%s" (regexp-quote (ediprolog-prompt))) nil t)
(with-current-buffer (process-buffer proc)
(setq ediprolog-seen-prompt t)))))
\f
;;;###autoload
(defun ediprolog-dwim (&optional arg)
"Load current buffer into Prolog or post query (Do What I Mean).
If invoked on a line starting with `:-' or `?-', possibly
preceded by `%' and whitespace, call `ediprolog-interact' with
the query as argument. Otherwise, call `ediprolog-consult'.
With prefix argument 0, kill the Prolog process. With prefix 1,
equivalent to `ediprolog-consult'. With prefix 2, equivalent to
`ediprolog-consult' with a new Prolog process. With prefix 7,
equivalent to `ediprolog-toplevel'. With just C-u, first call
`ediprolog-consult' and then, if point is on a query, call
`ediprolog-interact' with it as argument. Analogously, C-u C-u
for `ediprolog-consult' with a new process. With other prefix
arguments, equivalent to `ediprolog-remove-interactions'."
(interactive "P")
(cond ((eq arg 0)
(unless (ediprolog-running)
(error "No Prolog process running"))
(ediprolog-kill-prolog)
(message "Prolog process killed."))
((eq arg 1) (ediprolog-consult))
((eq arg 2) (ediprolog-consult t))
((eq arg 7)
(unless (ediprolog-more-solutions)
(error "No query in progress"))
(ediprolog-toplevel))
((equal arg '(4)) (ediprolog-consult) (ediprolog-query))
((equal arg '(16)) (ediprolog-consult t) (ediprolog-query))
((null arg) (unless (ediprolog-query) (ediprolog-consult)))
(t (ediprolog-remove-interactions))))
(defun ediprolog-process-ready ()
"Error if the previous query is still in progress."
(when (and ediprolog-interrupted
(ediprolog-running)
(ediprolog-more-solutions))
(error "Previous query still in progress, see `ediprolog-toplevel'"))
(setq ediprolog-interrupted nil))
(defun ediprolog-query ()
"If point is on a query, send it to the process and start interaction."
(ediprolog-process-ready)
(when (and (not (and transient-mark-mode mark-active))
(save-excursion
(beginning-of-line)
(looking-at "\\([\t ]*\\)%*[\t ]*[:?]- *")))
;; whitespace preceding the query is the indentation level
(setq ediprolog-indent-prefix (match-string 1))
(let* ((from (goto-char (match-end 0)))
(to (if (re-search-forward "\\.[\t ]*\\(?:%.*\\)?$" nil t)
;; omit trailing whitespace
(+ (point) (skip-chars-backward "\t "))
(error "Missing `.' at the end of this query")))
(query (buffer-substring-no-properties from to))
(handle (and (fboundp 'prepare-change-group)
(fboundp 'undo-amalgamate-change-group)
(cons t (prepare-change-group)))))
(end-of-line)
(insert "\n" ediprolog-indent-prefix ediprolog-prefix)
(ediprolog-interact
(format "%s\n"
(if (eq ediprolog-system 'scryer)
;; Scryer Prolog emits no additional indicators
;; when a query spans multiple lines, so we send
;; the query verbatim.
query
;; For other Prolog systems, we merge the query into
;; a single line. The drawback of this approach is
;; that single-line comments at the end of a line are
;; not handled correctly.
(mapconcat #'identity
;; `%' can precede each query line
(split-string query "\n[ \t%]*") " "))))
(when handle
(undo-amalgamate-change-group (cdr handle))))
t))
;;;###autoload
(defun ediprolog-interact (query)
"Send QUERY to Prolog process and interact as on a terminal.
You can use \\[keyboard-quit] to unblock Emacs in the case of
longer-running queries. When the query completes and the toplevel
asks for input, use \\[ediprolog-toplevel] to resume interaction
with the Prolog process."
(unless (ediprolog-running)
(ediprolog-run-prolog))
(set-marker (process-mark ediprolog-process) (point))
(set-process-buffer ediprolog-process (current-buffer))
(set-process-filter ediprolog-process 'ediprolog-interact-filter)
(ediprolog-ensure-buffer "temp")
(with-current-buffer ediprolog-temp-buffer
(let (buffer-read-only)
(erase-buffer)))
(setq ediprolog-seen-prompt nil
ediprolog-read-term nil)
(ediprolog-send-string query)
(ediprolog-toplevel))
(defun ediprolog-send-string (str)
"Send string to Prolog process and log it."
(ediprolog-log str "cyan")
(process-send-string ediprolog-process str))
(defun ediprolog-toplevel ()
"Start or resume Prolog toplevel interaction in the buffer.
You can use this function if you have previously quit (with
\\[keyboard-quit]) waiting for a longer-running query and now
want to resume interaction with the toplevel."
(interactive)
(when ediprolog-process
(select-window (display-buffer (process-buffer ediprolog-process))))
(ediprolog-remember-interruption
(while (ediprolog-more-solutions)
(let (str
char)
;; poll for user input; meanwhile, process output can arrive
(while (and (ediprolog-more-solutions) (null str))
(goto-char (process-mark ediprolog-process))
(if ediprolog-read-term
(progn
(setq str (concat (read-string "Input: ") "\n"))
(ediprolog-insert-at-marker
str ediprolog-indent-prefix ediprolog-prefix)
(setq ediprolog-read-term nil))
(condition-case nil
(when (setq char (if (>= emacs-major-version 22)
(read-char nil nil 0.1)
(with-timeout (0.1 nil)
(read-char))))
;; char-to-string might still yield an error (C-0 etc.)
(setq str (char-to-string char)))
(error
(message "Non-character key")
;; non-character keys must not remain in the input
;; buffer, lest `read-char' return immediately
(discard-input)))))
(when (ediprolog-more-solutions)
(if (eq char ?\C-c) ; char can be nil too
;; sending C-c directly yields strange SWI buffering
(interrupt-process ediprolog-process)
(ediprolog-send-string str)))))))
;;;###autoload
(defun ediprolog-remove-interactions ()
"Remove all lines starting with `ediprolog-prefix' from buffer.
In transient mark mode, if the region is active, the function
operates on the region."
(interactive)
(save-excursion
(save-restriction
(when (and transient-mark-mode mark-active)
(narrow-to-region (region-beginning) (region-end)))
(goto-char (point-min))
(flush-lines (concat "^[\t ]*" (regexp-quote ediprolog-prefix)))))
(message "Interactions removed."))
\f
;;;###autoload
(defun ediprolog-consult (&optional new-process)
"Buffer is loaded into a Prolog process. If NEW-PROCESS is
non-nil, start a new process. Otherwise use the existing process,
if any. In case of errors, point is moved to the position of the
first error, and the mark is left at the previous position.
In transient mark mode, if the region is active, the function
operates on the region."
(interactive)
(when (string= (buffer-name) ediprolog-consult-buffer)
(error "Cannot consult the consult buffer"))
(when (window-live-p ediprolog-consult-window)
(condition-case nil
;; deleting the window can still raise an error, if the window
;; was the only window in the frame and the consult buffer was
;; killed (and it thus displays a different buffer now)
(delete-window ediprolog-consult-window)
(error nil)))
(when (buffer-live-p ediprolog-consult-buffer)
(bury-buffer ediprolog-consult-buffer))
(when new-process
(ediprolog-kill-prolog))
(unless (ediprolog-running)
(ediprolog-run-prolog))
(ediprolog-process-ready)
(set-process-buffer ediprolog-process (current-buffer))
(when (or (null ediprolog-temp-file)
(and buffer-file-name
(not (equal (file-remote-p ediprolog-temp-file)
(file-remote-p buffer-file-name)))))
(setq ediprolog-temp-file
(funcall (if (fboundp 'make-nearby-temp-file)
'make-nearby-temp-file
'make-temp-file)
"ediprolog")))
(let ((start (if (and transient-mark-mode mark-active)
(region-beginning) (point-min)))
(end (if (and transient-mark-mode mark-active)
(region-end) (point-max))))
(write-region start end ediprolog-temp-file nil 'silent))
(set-process-filter ediprolog-process 'ediprolog-consult-filter)
(ediprolog-remember-interruption
(ediprolog-wait-for-prompt-after
(ediprolog-send-string (format "['%s'].\n"
(if (fboundp 'file-local-name)
(file-local-name ediprolog-temp-file)
ediprolog-temp-file)))))
(message "%s consulted." (if (and transient-mark-mode mark-active)
"Region" "Buffer"))
;; go to line of the first error, if any
(let ((line (with-current-buffer ediprolog-temp-buffer
(when (save-excursion
(goto-char (point-min))
(re-search-forward "^ERROR.*?:\\([0-9]+\\)" nil t))
(string-to-number (match-string 1))))))
(when line
(let ((p (point)))
(goto-char (if (and transient-mark-mode mark-active)
(region-beginning)
(point-min)))
;; doing this first would affect (region-beginning)
(push-mark p))
(forward-line (1- line)))))
(defun ediprolog-running ()
"True iff `ediprolog-process' is a running process."
(and (processp ediprolog-process)
(eq (process-status ediprolog-process) 'run)))
(defun ediprolog-more-solutions ()
"True iff there could be more solutions from the process."
(not ediprolog-seen-prompt))
(defun ediprolog-interact-filter (proc string)
"Insert output from the process and update the state."
(when (and (buffer-live-p (ediprolog-temp-buffer proc))
(buffer-live-p (process-buffer proc)))
(let (str)
(with-current-buffer (ediprolog-temp-buffer proc)
(goto-char (point-max))
(let (buffer-read-only)
(insert string))
(with-current-buffer (process-buffer proc)
(ediprolog-log string))
;; read a term from the user?
(when (re-search-backward "^|: $" nil t)
(with-current-buffer (process-buffer proc)
(setq ediprolog-read-term t))
(setq str (buffer-string))
(let (buffer-read-only)
(erase-buffer)))
;; check for prompt
(goto-char (point-max))
(when (re-search-backward
(format "^%s" (regexp-quote (ediprolog-prompt))) nil t)
(with-current-buffer (process-buffer proc)
(setq ediprolog-seen-prompt t))
;; ignore further output due to accidental user input (C-j,
;; C-m, etc.) while the query was running
(set-process-filter proc 'ediprolog-ignore-filter)
(skip-chars-backward "\n")
(setq str (buffer-substring (point-min) (point))))
(unless str
(goto-char (point-max))
;; delay final line if it can still be completed to prompt
(let ((l (buffer-substring (line-beginning-position) (point))))
(when (and (<= (length l) (length (ediprolog-prompt)))
(string= l (substring (ediprolog-prompt) 0 (length l))))
(goto-char (line-beginning-position))))
;; delay emitting newlines until we are sure no prompt
;; follows; one or two newlines can precede a prompt
(let ((d (abs (skip-chars-backward "\n"))))
(when (> d 2)
(forward-char (- d 2))))
(setq str (buffer-substring (point-min) (point)))
(let (buffer-read-only)
(delete-region (point-min) (point))))
(when str
(with-temp-buffer
;; precede each line with ediprolog prefices
(insert str)
(goto-char (point-min))
(while (search-forward "\n" nil t)
(replace-match
(format "\n%s%s"
(buffer-local-value 'ediprolog-indent-prefix
(process-buffer proc))
(buffer-local-value 'ediprolog-prefix
(process-buffer proc)))))
(setq str (buffer-string)))
(with-current-buffer (process-buffer proc)
(let ((near (<= (abs (- (point) (process-mark proc))) 1)))
(ediprolog-insert-at-marker str)
(when near
;; catch up with output if point was reasonably close
(goto-char (process-mark proc))))))))))
(defun ediprolog-insert-at-marker (&rest args)
"Insert strings ARGS at marker and update the marker."
(save-excursion
(goto-char (process-mark ediprolog-process))
(end-of-line)
(apply #'insert args)
(set-marker (process-mark ediprolog-process) (point))))
(defun ediprolog-ignore-filter (proc str)
"Log and then ignore all process output."
(with-current-buffer (process-buffer proc)
(ediprolog-log str "gray")))
(defun ediprolog-temp-buffer (proc)
(with-current-buffer (process-buffer proc)
;; temp buffer can be buffer local
ediprolog-temp-buffer))
(defun ediprolog-map-variables (func)
"Call FUNC with all ediprolog variables that can become buffer-local."
(mapc func '(ediprolog-process
ediprolog-system
ediprolog-program
ediprolog-program-switches
ediprolog-temp-buffer
ediprolog-history-buffer
ediprolog-seen-prompt
ediprolog-interrupted
ediprolog-read-term
ediprolog-indent-prefix
ediprolog-prefix
ediprolog-temp-file)))
;;;###autoload
(defun ediprolog-localize ()
"After `ediprolog-localize', any Prolog process started from
this buffer becomes buffer-local."
(interactive)
(unless (local-variable-p 'ediprolog-process)
(ediprolog-map-variables #'make-local-variable)
(setq ediprolog-temp-file nil
ediprolog-process nil
ediprolog-history-buffer nil
ediprolog-temp-buffer nil)))
(defun ediprolog-unlocalize ()
"Revert the effect of `ediprolog-localize'."
(interactive)
(when (local-variable-p 'ediprolog-process)
(ediprolog-kill-prolog)
(ediprolog-map-variables #'kill-local-variable)))
(provide 'ediprolog)
;;; ediprolog.el ends here
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2022-09-30 16:59 bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Markus Triska
@ 2022-10-01 12:56 ` Lars Ingebrigtsen
2022-10-01 14:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
` (4 subsequent siblings)
5 siblings, 0 replies; 35+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-01 12:56 UTC (permalink / raw)
To: Markus Triska; +Cc: Stefan Monnier, 58196
Markus Triska <triska@metalevel.at> writes:
> ediprolog 2.2 is now available from:
>
> https://www.metalevel.at/ediprolog/ediprolog.el
[...]
> Could you please upload the new release to ELPA?
We normally prefer to get the full VC history of package in ELPA instead
of doing updates like this, but I guess doing it this way would be fine,
too.
I've added Stefan to the CCs; perhaps he has some comments.
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2022-09-30 16:59 bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Markus Triska
2022-10-01 12:56 ` Lars Ingebrigtsen
@ 2022-10-01 14:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-01 17:01 ` Markus Triska
2022-10-18 14:34 ` bug#58196: Trivial update to ediprolog Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
` (3 subsequent siblings)
5 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-01 14:57 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
> ediprolog 2.2 is now available from:
>
> https://www.metalevel.at/ediprolog/ediprolog.el
[...]
> Could you please upload the new release to ELPA?
Could you make that available on a public Git repository somewhere
(eg. `repo.or.cz`, `codeberg.org`, ...)?
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2022-10-01 14:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-01 17:01 ` Markus Triska
2022-10-01 18:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2022-10-01 17:01 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 58196
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Could you make that available on a public Git repository somewhere
> (eg. `repo.or.cz`, `codeberg.org`, ...)?
Yes, I have made a public repository available at:
https://github.com/triska/ediprolog/
The history of ediprolog.el is available from:
https://github.com/triska/ediprolog/commits/master/ediprolog.el
The changes relative to 2.1 are:
https://github.com/triska/ediprolog/commit/5fd08fe19a71876da4cfc21b81fbc04af9890cba
https://github.com/triska/ediprolog/commit/85fae67aeaede36ba61b0c551aa18617d3b9f797
https://github.com/triska/ediprolog/commit/ebd79c0abdc05a752c947e333551d808e3933046
https://github.com/triska/ediprolog/commit/dc0e51ba579f2eb26ae0cdc733104e8861f04c10
The release of 2.1 was:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41765
Please let me know if anything else is needed.
Thank you and all the best,
Markus
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2022-10-01 17:01 ` Markus Triska
@ 2022-10-01 18:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-02 19:49 ` Markus Triska
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-01 18:37 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
> Yes, I have made a public repository available at:
>
> https://github.com/triska/ediprolog/
Could you merge that history with that of elpa.git?
I.e. start with
git remote add -p externals/ediprolog elpa \
git://git.sv.gnu.org/emacs/elpa.git
and then try something like
git merge elpa/externals/ediprolog
It might be rather messy done this way. You may need to start by
merging the elpa history with the closest matching version in your
history (maybe commit 751119cfee9efb52e89d0387d795f3b0c181299d?):
git reset --hard 751119cfee9efb52e89d0387d795f3b0c181299d
git merge elpa/externals/ediprolog
[ resolve any conflicts, and make any other changes you like ]
git merge
elpa.git won't be able to follow your repository until that repository's
HEAD is a "fast forward" so this "merging" is necessary. You can make
it "trivial" by throwing away any and all changes that actually come
from `elpa/externals/ediprolog`: only the metadata needs to say that
the commits of `elpa/externals/ediprolog` have all been merged.
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2022-10-01 18:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-02 19:49 ` Markus Triska
2022-10-02 20:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2022-10-02 19:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 58196
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Could you merge that history with that of elpa.git?
OK, I have uploaded the changes as a series of patches at:
https://www.metalevel.at/ediprolog/ediprolog_2_2.patch
For completeness, I also attach the content at the end of this mail, and
I hope this suffices to update the package?
Thank you and all the best,
Markus
From 843ff2613207fdc557a5511d58664bb3859a7efa Mon Sep 17 00:00:00 2001
From: Markus Triska <triska@metalevel.at>
Date: Sun, 2 Oct 2022 21:43:08 +0200
Subject: [PATCH 1/4] improve compatibility with older Emacs versions
---
ediprolog.el | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/ediprolog.el b/ediprolog.el
index d88d30e80c..7898660d78 100644
--- a/ediprolog.el
+++ b/ediprolog.el
@@ -1,6 +1,6 @@
;;; ediprolog.el --- Emacs Does Interactive Prolog
-;; Copyright (C) 2006-2009, 2012-2013, 2016-2017, 2020 Free Software Foundation, Inc.
+;; Copyright (C) 2006-2009, 2012-2013, 2016-2017, 2021 Free Software Foundation, Inc.
;; Author: Markus Triska <triska@metalevel.at>
;; Keywords: languages, processes
@@ -39,7 +39,7 @@
;;
;; The two most important configuration options are:
;;
-;; - `ediprolog-system', either 'scryer or 'swi
+;; - `ediprolog-system', either 'scryer (default) or 'swi
;; - `ediprolog-program', the path of the Prolog executable.
;; Usage
@@ -491,7 +491,11 @@ operates on the region."
(and buffer-file-name
(not (equal (file-remote-p ediprolog-temp-file)
(file-remote-p buffer-file-name)))))
- (setq ediprolog-temp-file (make-nearby-temp-file "ediprolog")))
+ (setq ediprolog-temp-file
+ (funcall (if (fboundp 'make-nearby-temp-file)
+ 'make-nearby-temp-file
+ 'make-temp-file)
+ "ediprolog")))
(let ((start (if (and transient-mark-mode mark-active)
(region-beginning) (point-min)))
(end (if (and transient-mark-mode mark-active)
--
2.17.2 (Apple Git-113)
From d02540902f2a71e6f1888f9db6845d6adb3c1ae1 Mon Sep 17 00:00:00 2001
From: Markus Triska <triska@metalevel.at>
Date: Sun, 2 Oct 2022 21:45:04 +0200
Subject: [PATCH 2/4] handle answers of recent Scryer Prolog versions
---
ediprolog.el | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ediprolog.el b/ediprolog.el
index 7898660d78..a74e5f13a7 100644
--- a/ediprolog.el
+++ b/ediprolog.el
@@ -273,9 +273,9 @@ set_prolog_flag(toplevel_prompt, '%s').\n" (ediprolog-prompt)))))
;; success (i.e., consulted without errors), or still an incomplete
;; line that starts with a comment character
(unless (or (string-match "^[\t ]*\\(?:%.*\\)?\\'" str)
- (let ((success "true."))
- (and (<= (length str) (length success))
- (string= str (substring success 0 (length str))))))
+ (string-prefix-p str "true.")
+ ;; newer versions of Scryer Prolog prepend 3 spaces to "true."
+ (string-prefix-p str " true."))
(setq ediprolog-consult-window (display-buffer ediprolog-consult-buffer))
(set-window-dedicated-p ediprolog-consult-window t)
(fit-window-to-buffer ediprolog-consult-window (/ (frame-height) 2))))
--
2.17.2 (Apple Git-113)
From 6e137449e2b1b711dfba9d04526472a5cd8f9447 Mon Sep 17 00:00:00 2001
From: Markus Triska <triska@metalevel.at>
Date: Sun, 2 Oct 2022 21:46:56 +0200
Subject: [PATCH 3/4] faithful processing of multiline queries when using
Scryer Prolog
---
ediprolog.el | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/ediprolog.el b/ediprolog.el
index a74e5f13a7..f44914b60b 100644
--- a/ediprolog.el
+++ b/ediprolog.el
@@ -1,6 +1,6 @@
;;; ediprolog.el --- Emacs Does Interactive Prolog
-;; Copyright (C) 2006-2009, 2012-2013, 2016-2017, 2021 Free Software Foundation, Inc.
+;; Copyright (C) 2006-2009, 2012-2013, 2016-2017, 2021-2022 Free Software Foundation, Inc.
;; Author: Markus Triska <triska@metalevel.at>
;; Keywords: languages, processes
@@ -53,11 +53,11 @@
;; Queries start with "?-" or ":-", possibly preceded by "%" and
;; whitespace. An example of a query is (without leading ";;"):
;;
-;; %?- member(X, [a,b,c]).
+;; %?- member(X, "abc").
;;
;; If you press F10 when point is on that query, you get:
;;
-;; %?- member(X, [a,b,c]).
+;; %?- member(X, "abc").
;; %@ X = a
;; %@ ; X = b
;; %@ ; X = c
@@ -370,9 +370,19 @@ arguments, equivalent to `ediprolog-remove-interactions'."
(end-of-line)
(insert "\n" ediprolog-indent-prefix ediprolog-prefix)
(ediprolog-interact
- (format "%s\n" (mapconcat #'identity
+ (format "%s\n"
+ (if (eq ediprolog-system 'scryer)
+ ;; Scryer Prolog emits no additional indicators
+ ;; when a query spans multiple lines, so we send
+ ;; the query verbatim.
+ query
+ ;; For other Prolog systems, we merge the query into
+ ;; a single line. The drawback of this approach is
+ ;; that single-line comments at the end of a line are
+ ;; not handled correctly.
+ (mapconcat #'identity
;; `%' can precede each query line
- (split-string query "\n[ \t%]*") " ")))
+ (split-string query "\n[ \t%]*") " "))))
(when handle
(undo-amalgamate-change-group (cdr handle))))
t))
--
2.17.2 (Apple Git-113)
From 22fa75d0f73791a3765e3eebbb552a852091b925 Mon Sep 17 00:00:00 2001
From: Markus Triska <triska@metalevel.at>
Date: Sun, 2 Oct 2022 21:48:03 +0200
Subject: [PATCH 4/4] ediprolog version 2.2
New in this version:
* handle answers of recent Scryer Prolog versions
* faithful processing of multiline queries when using Scryer Prolog
* improved compatibility with older Emacs versions
---
ediprolog.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ediprolog.el b/ediprolog.el
index f44914b60b..8d36607805 100644
--- a/ediprolog.el
+++ b/ediprolog.el
@@ -93,7 +93,7 @@
;;; Code:
-(defconst ediprolog-version "2.1")
+(defconst ediprolog-version "2.2")
(defgroup ediprolog nil
"Transparent interaction with Prolog."
--
2.17.2 (Apple Git-113)
^ permalink raw reply related [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2022-10-02 19:49 ` Markus Triska
@ 2022-10-02 20:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-02 20:24 ` Markus Triska
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-02 20:07 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
Markus Triska [2022-10-02 21:49:45] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Could you merge that history with that of elpa.git?
>
> OK, I have uploaded the changes as a series of patches at:
>
> https://www.metalevel.at/ediprolog/ediprolog_2_2.patch
>
> For completeness, I also attach the content at the end of this mail, and
> I hope this suffices to update the package?
No, that's not what I'm after. I want `git merge` to work. So I need
you to merge that specific commit into your upstream repository so that
elpa.git can then follow your repository. The important part is all in
the *meta*data, not in the file's contents.
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2022-10-02 20:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-02 20:24 ` Markus Triska
2022-10-02 21:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2022-10-02 20:24 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 58196
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> No, that's not what I'm after. I want `git merge` to work. So I need
> you to merge that specific commit into your upstream repository so that
> elpa.git can then follow your repository. The important part is all in
> the *meta*data, not in the file's contents.
Due to other commitments, I unfortunately cannot help further with these
issues which seem very complex to me (I do not even know what you mean
with the *meta*data). If what I provided unexpectedly no longer suffices
to upload the latest release to ELPA (in all previous releases,
announcing the newest version sufficed), could you please remove
ediprolog from ELPA? It seems best not to provide an outdated version.
Thank you and all the best,
Markus
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2022-10-02 20:24 ` Markus Triska
@ 2022-10-02 21:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-03 0:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-02 21:08 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
Markus Triska [2022-10-02 22:24:15] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> No, that's not what I'm after. I want `git merge` to work. So I need
>> you to merge that specific commit into your upstream repository so that
>> elpa.git can then follow your repository. The important part is all in
>> the *meta*data, not in the file's contents.
>
> Due to other commitments, I unfortunately cannot help further with these
> issues which seem very complex to me (I do not even know what you mean
> with the *meta*data).
The metadata is the info Git saves about the history of the package.
It uses it for example to know how to do an update when you fetch updates.
> If what I provided unexpectedly no longer suffices
> to upload the latest release to ELPA (in all previous releases,
> announcing the newest version sufficed), could you please remove
> ediprolog from ELPA? It seems best not to provide an outdated version.
If you need help with Git I can do that.
I just did the merge I suggested and the result is in the
`scratch/ediprolog` branch in `elpa.git`.
So all you need to do is to merge that code into your repository, is
the following:
cd .../where/you/keep/your/clone/of/ediprolog/
git fetch --single-branch scratch/ediprolog git://git.sv.gnu.org/emacs/elpa.git
git merge FETCH_HEAD
and then `git push` the result to your repository.
I appended below my signature the changes that this `merge` will apply
to your code (beside the changes to the metadata). The `.gitignore`
file is not indispensable but is very handy for other people using your
Git repository (or its mirror in elpa.git), but the other two changes
are indispensable because GNU ELPA needs the `Version:` header to know
what is the version of your package (and when a new version is
released), and it checks the copyright headers which state that the
files are covered by copyright assignments.
Stefan
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000..7aa352d86f
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+/ediprolog-pkg.el
+/ediprolog-autoloads.el
+*.elc
diff --git a/ediprolog.el b/ediprolog.el
index 035c7b7443..033aacd208 100644
--- a/ediprolog.el
+++ b/ediprolog.el
@@ -1,9 +1,10 @@
;;; ediprolog.el --- Emacs Does Interactive Prolog
-;; Copyright (C) 2006-2022 Markus Triska
+;; Copyright (C) 2006-2022 Free Software Foundation, Inc.
;; Author: Markus Triska <triska@metalevel.at>
;; Keywords: languages, processes
+;; Version: 2.2
;; Homepage: https://www.metalevel.at/ediprolog/
;; This file is free software; you can redistribute it and/or modify
^ permalink raw reply related [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-09-30 16:59 bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Markus Triska
2022-10-01 12:56 ` Lars Ingebrigtsen
2022-10-01 14:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-18 14:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-26 13:26 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-22 16:20 ` Markus Triska
` (2 subsequent siblings)
5 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-18 14:34 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
Hi,
Could you do:
cd .../where/you/keep/your/clone/of/ediprolog/
git fetch git://git.sv.gnu.org/emacs/elpa.git scratch/ediprolog
git merge FETCH_HEAD
so as to merge the few minor changes we had over in elpa.git?
It will make 2 changes:
- Change copyright line to make it compatible with GNU ELPA requirements.
- Add a `Version: 2.2` header line so GNU ELPA can make a release of the
new code.
- Tell Git that those changes have been merged, so it can properly track
future changes from your repository.
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-18 14:34 ` bug#58196: Trivial update to ediprolog Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-26 13:26 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-26 13:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-26 13:26 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
> It will make 2 changes:
>
> - Change copyright line to make it compatible with GNU ELPA requirements.
> - Add a `Version: 2.2` header line so GNU ELPA can make a release of the
> new code.
> - Tell Git that those changes have been merged, so it can properly track
> future changes from your repository.
I added a hack in GNU ELPA's scripts to deal with the third point, but
the other two are still a problem:
- As long as you use another copyright line, every time you make a change
to that line, the automatic merge will fail because of a merge
conflict, so it will require manual intervention.
- As long as you don't use the `Version:` header, the scripts won't know
when you want to make a new release, so again manual intervention will
be needed every time you want to make a release.
Could you please please pretty please help me reduce my workload by
avoiding those needs for human intervention?
The best way you can do that is:
cd .../where/you/keep/your/clone/of/ediprolog/
git fetch git://git.sv.gnu.org/emacs/elpa.git scratch/ediprolog
git merge FETCH_HEAD
-- Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-26 13:26 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-26 13:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-27 21:11 ` Markus Triska
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-26 13:32 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
> The best way you can do that is:
>
> cd .../where/you/keep/your/clone/of/ediprolog/
> git fetch git://git.sv.gnu.org/emacs/elpa.git scratch/ediprolog
> git merge FETCH_HEAD
Actually, now a better choice would be:
cd .../where/you/keep/your/clone/of/ediprolog/
git fetch git://git.sv.gnu.org/emacs/elpa.git externals/ediprolog
git merge FETCH_HEAD
-- Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-26 13:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-27 21:11 ` Markus Triska
2022-10-28 2:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2022-10-27 21:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 58196
Thank you, I will look into this! One remaining issue I noticed is that
the formatting of the ELPA description page seems to be a bit broken
now, in particular (1) the result of the sample query and also (2) the
table showing the key sequences on this page:
https://elpa.gnu.org/packages/ediprolog.html
For comparison, this is how the page looked previously:
https://web.archive.org/web/20211016152552/https://elpa.gnu.org/packages/ediprolog.html
Note that the answer to the sample query is correctly formatted
(spanning multiple lines), and the table of key sequences is also shown
very readably.
Why does this issue arise, is this an issue of Markdown rendering, and
can I do anything to display the page as intended?
Thank you and all the best,
Markus
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-27 21:11 ` Markus Triska
@ 2022-10-28 2:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 3:06 ` Stefan Kangas
2022-10-28 3:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-28 2:08 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
> Thank you, I will look into this! One remaining issue I noticed is that
> the formatting of the ELPA description page seems to be a bit broken
> now, in particular (1) the result of the sample query
Hmm... that looks quite odd indeed. Looks like a bug in the markdown
rendering into HTML or a side-effect of the CSS we apply to it.
> and also (2) the
> table showing the key sequences on this page:
This one is normal/expected: we currently only support the "plainest"
markdown, not extensions like tables.
> Why does this issue arise, is this an issue of Markdown rendering, and
> can I do anything to display the page as intended?
If you happen to know a bit about HTML, it would help if you looked at
the generated HTML for the query result and tell me if the problem is in
the HTML itself or the CSS applied to it.
And if you know about markdown processors, it would help if you could
provide guidance as to which one to use and how to configure it so it
only supports a limited set of extensions (I'd rather not get tied to
a particular set of extensions only supported by a particular processor,
which is why I currently use the no-frills `markdown` from the
`markdown` Debian package).
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 2:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-28 3:06 ` Stefan Kangas
2022-10-28 3:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 6:35 ` Eli Zaretskii
2022-10-28 3:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 2 replies; 35+ messages in thread
From: Stefan Kangas @ 2022-10-28 3:06 UTC (permalink / raw)
To: Stefan Monnier, Markus Triska; +Cc: 58196
Stefan Monnier writes:
> And if you know about markdown processors, it would help if you could
> provide guidance as to which one to use and how to configure it so it
> only supports a limited set of extensions (I'd rather not get tied to
> a particular set of extensions only supported by a particular processor,
> which is why I currently use the no-frills `markdown` from the
> `markdown` Debian package).
It seems like the "markdown" package is now orphaned in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466330
That package seems to have been in life support for a decade or more,
based on the Debian changelog and the above discussion.
How about using python-markdown instead? It seems to be actively
maintained and no-frills enough. See:
https://python-markdown.github.io/#goals
It has optional extensions, such as one for tables.
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 3:06 ` Stefan Kangas
@ 2022-10-28 3:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 6:35 ` Eli Zaretskii
1 sibling, 0 replies; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-28 3:35 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Markus Triska, 58196
> How about using python-markdown instead? It seems to be actively
> maintained and no-frills enough. See:
>
> https://python-markdown.github.io/#goals
>
> It has optional extensions, such as one for tables.
I ended up using https://github.com/trentm/python-markdown2
instead. The choice was largely arbitrary, but markdown2 was smaller,
claims to be faster, and had one less dependency.
So, from now on, tables should start working (not in existing pages,
tho: it'll only start working after a new tarball gets built).
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 3:06 ` Stefan Kangas
2022-10-28 3:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-28 6:35 ` Eli Zaretskii
2022-10-28 12:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2022-10-28 6:35 UTC (permalink / raw)
To: Stefan Kangas; +Cc: monnier, 58196, triska
> Cc: 58196@debbugs.gnu.org
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 27 Oct 2022 20:06:34 -0700
>
> Stefan Monnier writes:
>
> > And if you know about markdown processors, it would help if you could
> > provide guidance as to which one to use and how to configure it so it
> > only supports a limited set of extensions (I'd rather not get tied to
> > a particular set of extensions only supported by a particular processor,
> > which is why I currently use the no-frills `markdown` from the
> > `markdown` Debian package).
>
> It seems like the "markdown" package is now orphaned in Debian:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466330
>
> That package seems to have been in life support for a decade or more,
> based on the Debian changelog and the above discussion.
>
> How about using python-markdown instead? It seems to be actively
> maintained and no-frills enough. See:
>
> https://python-markdown.github.io/#goals
>
> It has optional extensions, such as one for tables.
How about adding markdown support to core instead? It shouldn't be
hard to whip up a decent markdown mode for Emacs, and I recently
learned that Eglot works much better when such a mode is available.
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 6:35 ` Eli Zaretskii
@ 2022-10-28 12:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-28 12:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stefan Kangas, triska, 58196
> How about adding markdown support to core instead?
Sounds good to me, tho I'm not sure about the "instead": the discussion
to which you replied related to the code used to generate the HTML files
for elpa.gnu.org, whereas a "Markdown support in core" may not
necessarily support the generation of HTML (and would instead focus on
rendering Markdown into an Emacs buffer).
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 2:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 3:06 ` Stefan Kangas
@ 2022-10-28 3:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 16:49 ` Markus Triska
1 sibling, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-28 3:09 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
>> Thank you, I will look into this! One remaining issue I noticed is that
>> the formatting of the ELPA description page seems to be a bit broken
>> now, in particular (1) the result of the sample query
>
> Hmm... that looks quite odd indeed. Looks like a bug in the markdown
> rendering into HTML or a side-effect of the CSS we apply to it.
Apparently it's a problem in the CSS. I installed a change which seems
to fix it, but there's probably a more elegant and reliable way to do it.
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 3:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-28 16:49 ` Markus Triska
2022-10-28 18:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2022-10-28 16:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 58196
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Apparently it's a problem in the CSS. I installed a change which seems
> to fix it, but there's probably a more elegant and reliable way to do it.
Thank you a lot! I the meantime, I noticed a few additional issues:
1) Text that is intended to be bold is sometimes not shown in bold. For
example, even though line 76 of README.md starts with:
Use **M-x ediprolog-localize RET** to make any Prolog process
the text 'M-x ediprolog-localize RET' is not displayed in bold.
2) The link to ediprolog.el (line 23 of README.md) does not work.
3) The image in line 101 of README.md is not shown.
Do you think they can also be solved, so that they work as intended?
Thank you and all the best!
Markus
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 16:49 ` Markus Triska
@ 2022-10-28 18:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 20:01 ` Stefan Kangas
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-28 18:07 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
Markus Triska [2022-10-28 18:49:51] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Apparently it's a problem in the CSS. I installed a change which seems
>> to fix it, but there's probably a more elegant and reliable way to do it.
> 1) Text that is intended to be bold is sometimes not shown in bold. For
> example, even though line 76 of README.md starts with:
>
> Use **M-x ediprolog-localize RET** to make any Prolog process
>
> the text 'M-x ediprolog-localize RET' is not displayed in bold.
I think this is fixed now, thanks.
> 2) The link to ediprolog.el (line 23 of README.md) does not work.
Relative links don't work, indeed. I don't know how we could/should fix them.
We don't actually have an `ediprolog.el` file nearby in the website.
In this particular case, I think the better option is just to remove the
link and the whole discussion of how to install it, since that's the
same as for all other packages :-)
[ And some of that info is already mentioned earlier in
https://elpa.gnu.org/packages/ediprolog.html ]
> 3) The image in line 101 of README.md is not shown.
I think it's the same problem that the relative link to `factorial.png`
fails. The case is a bit different in the sense that I can't argue this
time that the link is redundant anyway :-)
Maybe we could try and recognize those links and redirect them to something like
https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/factorial.png?h=externals/ediprolog
but going through `cgit` is rather inefficient (and recognizing those
links reliably is not completely trivial either).
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 18:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-28 20:01 ` Stefan Kangas
2022-10-28 20:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Kangas @ 2022-10-28 20:01 UTC (permalink / raw)
To: Stefan Monnier, Markus Triska; +Cc: 58196
Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:
>> 3) The image in line 101 of README.md is not shown.
>
> I think it's the same problem that the relative link to `factorial.png`
> fails. The case is a bit different in the sense that I can't argue this
> time that the link is redundant anyway :-)
>
> Maybe we could try and recognize those links and redirect them to something like
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/factorial.png?h=externals/ediprolog
> but going through `cgit` is rather inefficient (and recognizing those
> links reliably is not completely trivial either).
We could just copy any image files to the web directory, and add some
heuristics to change any <img>-tags in the HTML (exported from
markdown2, org-mode, etc.) to point there.
For example, we could put factorial.png in
/images/<package-name>/factorial.png. The only cost is a bit of
diskspace, but it shouldn't be a lot as there is already some incentive
to keep down file sizes.
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 20:01 ` Stefan Kangas
@ 2022-10-28 20:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 20:51 ` Stefan Kangas
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-28 20:20 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Markus Triska, 58196
> For example, we could put factorial.png in
> /images/<package-name>/factorial.png. The only cost is a bit of
But the page which links to it is not inside `/images/<package-name>/`
so the relative link will still fail.
I think we need to first move the packages's webpages from
https://elpa.gnu.org/packages/<PKG>.html
to
https://elpa.gnu.org/packages/<PKG>/index.html
and then we can more easily copy image files and anything else to
that subdirectory.
We have similar needs for the HTML-rendered `:doc`s which are placed into
https://elpa.gnu.org/packages/doc/<MANUAL>.html so we'd also want to
copy somefiles to that `doc` subdir. The problem is a bit worse there,
because that subdir is shared between all the packages so as to make it
possible to have relative links between manuals of different packages.
IOW we probably need to enforce that all the files that need to be
copied into the `doc` subdir are prefixed by the package name.
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 20:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-28 20:51 ` Stefan Kangas
2022-10-28 21:54 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Kangas @ 2022-10-28 20:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Markus Triska, 58196
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> For example, we could put factorial.png in
>> /images/<package-name>/factorial.png. The only cost is a bit of
>
> But the page which links to it is not inside `/images/<package-name>/`
> so the relative link will still fail.
I was thinking of using absolute but domain-specific links, i.e. moving
all images to the directory:
$WEBROOT/images/<package>
And then changing the img-tags to read:
<img src="/images/<package>/<image>">
That way, we don't need to worry about relative links. So, for example,
if we have an image named "screenshot.png" in the repository for
<package>, and it looks something like this in the raw HTML export:
<img src="https://cdn.github.com/foo/bar/screenshot.png">
We replace everything before the last "/" with "/images/<package>", or
indeed just add it there if the link is relative, so we end up with:
<img src="/images/<package>/screenshot.png">
Does that make sense?
> I think we need to first move the packages's webpages from
>
> https://elpa.gnu.org/packages/<PKG>.html
>
> to
>
> https://elpa.gnu.org/packages/<PKG>/index.html
>
> and then we can more easily copy image files and anything else to
> that subdirectory.
That's another option, yes. That would allow us to use relative links.
Do we anticipate more things going in that directory, too? Perhaps some
packages will ship with some non-documentation resource files that don't
belong in $WEBROOT/doc? If so, this option might be cleaner in the long
run.
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-28 20:51 ` Stefan Kangas
@ 2022-10-28 21:54 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-28 21:54 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Markus Triska, 58196
Stefan Kangas [2022-10-28 13:51:32] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> For example, we could put factorial.png in
>>> /images/<package-name>/factorial.png. The only cost is a bit of
>>
>> But the page which links to it is not inside `/images/<package-name>/`
>> so the relative link will still fail.
>
> I was thinking of using absolute but domain-specific links, i.e. moving
> all images to the directory:
>
> $WEBROOT/images/<package>
>
> And then changing the img-tags to read:
>
> <img src="/images/<package>/<image>">
>
> That way, we don't need to worry about relative links. So, for example,
> if we have an image named "screenshot.png" in the repository for
> <package>, and it looks something like this in the raw HTML export:
>
> <img src="https://cdn.github.com/foo/bar/screenshot.png">
>
> We replace everything before the last "/" with "/images/<package>", or
> indeed just add it there if the link is relative, so we end up with:
>
> <img src="/images/<package>/screenshot.png">
>
> Does that make sense?
>
>> I think we need to first move the packages's webpages from
>>
>> https://elpa.gnu.org/packages/<PKG>.html
>>
>> to
>>
>> https://elpa.gnu.org/packages/<PKG>/index.html
>>
>> and then we can more easily copy image files and anything else to
>> that subdirectory.
>
> That's another option, yes. That would allow us to use relative links.
It would also make for slightly shorter "home URL".
> Do we anticipate more things going in that directory, too?
All the old compressed tarballs would move there too, yes. And also the
output for `:doc` (which currently lives in a `.../doc/<package>/`
subdir instead).
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-09-30 16:59 bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Markus Triska
` (2 preceding siblings ...)
2022-10-18 14:34 ` bug#58196: Trivial update to ediprolog Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-22 16:20 ` Markus Triska
2022-10-22 16:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-23 7:29 ` Markus Triska
2024-01-10 10:54 ` bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Stefan Kangas
5 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2022-10-22 16:20 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 58196
Thank you! Please do keep these changes in the ELPA version of the file,
since they are specific to ELPA. The git repository of ediprolog
provides the master copy of ediprolog.el, and I will keep it as it is.
In a previous mail in this thread, I have provided a patchset relative
to the current ELPA version of ediprolog.el that incorporates all latest
developments from the master version which I provide on the ediprolog
page and also on github. If possible, please use the patchset to update
the ELPA version, and make any ELPA-specific adjustments as necessary.
Unfortunately I cannot help further, so I hope this suffices.
Thank you and all the best,
Markus
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Hi,
>
> Could you do:
>
> cd .../where/you/keep/your/clone/of/ediprolog/
> git fetch git://git.sv.gnu.org/emacs/elpa.git scratch/ediprolog
> git merge FETCH_HEAD
>
> so as to merge the few minor changes we had over in elpa.git?
> It will make 2 changes:
>
> - Change copyright line to make it compatible with GNU ELPA requirements.
> - Add a `Version: 2.2` header line so GNU ELPA can make a release of the
> new code.
> - Tell Git that those changes have been merged, so it can properly track
> future changes from your repository.
>
>
> Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-22 16:20 ` Markus Triska
@ 2022-10-22 16:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-22 16:51 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
Hi Markus,
> Thank you! Please do keep these changes in the ELPA version of the file,
> since they are specific to ELPA.
I don't see why you think they are specific to GNU ELPA.
E.g. the `Version:` header is a convention followed by most packages
nowadays and used by various tools, whereas your `ediprolog-version`
variable is not used even by your code (or doc).
> The git repository of ediprolog provides the master copy of
> ediprolog.el, and I will keep it as it is.
So you do not want to add a `Version:` line and you do not want to
change the copyright line to say that it is owned by the FSF?
Could you explain why?
The `git merge` dance I'm asking you to do is expected to be a one-time
occurrence, not something that you'll need to do for every release.
[ BTW, you've signed the copyright paperwork which transferred the
copyright to the FSF, so you technically do not own the copyright to
that file any more, so your upstream code's copyright line is
incorrect. ]
> In a previous mail in this thread, I have provided a patchset relative
> to the current ELPA version of ediprolog.el that incorporates all latest
> developments from the master version which I provide on the ediprolog
> page and also on github. If possible, please use the patchset to update
> the ELPA version, and make any ELPA-specific adjustments as necessary.
There are enough packages in (Non)GNU ELPA that we try to avoid such
manual work. Instead changes are automatically pulled from upstream
repositories and new packages are released without further human
intervention. More specifically the only human intervention needed to
cause a new release is the upstream maintainer's modification of the
`Version:` line.
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-09-30 16:59 bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Markus Triska
` (3 preceding siblings ...)
2022-10-22 16:20 ` Markus Triska
@ 2022-10-23 7:29 ` Markus Triska
2022-10-25 19:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 10:54 ` bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Stefan Kangas
5 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2022-10-23 7:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 58196
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> [ BTW, you've signed the copyright paperwork which transferred the
> copyright to the FSF, so you technically do not own the copyright to
> that file any more, so your upstream code's copyright line is
> incorrect. ]
The jurisdiction where I reside guarantees authors' rights as opposed to
copyright. Certain rights I have as the sole author of ediprolog.el
cannot be transferred, except by inheritance, even if I wanted to
transfer them (§ 23 Abs. 3 UrhG). The rights I have as the author of
ediprolog.el include the right to decide whether and how to display that
I am its author (§ 20 Abs. 1 UrhG).
In the master file of ediprolog.el, I am using the copyright notice as
the usual way ("übliche Weise") in which authorship is indicated in
code. This is to satisfy the conditions of § 12 UrhG to indicate me as
the author of the code. Since I am the author, the notice it correct.
I have the rights I mentioned also without this notice, and therefore I
accept changes you make to this notice if they are required to
distribute ediprolog.el on ELPA. The master file I provide in the
jurisdiction where I reside will retain the notice for the reason above.
Thank you and all the best,
Markus
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: Trivial update to ediprolog
2022-10-23 7:29 ` Markus Triska
@ 2022-10-25 19:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 35+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-25 19:49 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
>> [ BTW, you've signed the copyright paperwork which transferred the
>> copyright to the FSF, so you technically do not own the copyright to
>> that file any more, so your upstream code's copyright line is
>> incorrect. ]
>
> The jurisdiction where I reside guarantees authors' rights as opposed to
> copyright.
Yes, they use different names, but they work pretty much in the same way.
> Certain rights I have as the sole author of ediprolog.el
> cannot be transferred,
The same for copyright law in North America. They're just called
differently, but by and large they work the same.
> except by inheritance, even if I wanted to transfer them (§ 23
> Abs. 3 UrhG). The rights I have as the author of ediprolog.el include
> the right to decide whether and how to display that I am its author (§
> 20 Abs. 1 UrhG).
>
> In the master file of ediprolog.el, I am using the copyright notice as
> the usual way ("übliche Weise") in which authorship is indicated in
> code. This is to satisfy the conditions of § 12 UrhG to indicate me as
> the author of the code. Since I am the author, the notice it correct.
Fine, then it's not technically incorrect, but it's still inconvenient
for us and it's misleading when interpreted based on the meaning of
those words in some other jurisdictions. In contrast, you also have
;; Author: Markus Triska <triska@metalevel.at>
in that file, which should be very clear to everyone and makes your
copyright line redundant (in addition to inconvenient for us and
misleading in some contexts).
> I have the rights I mentioned also without this notice, and therefore I
> accept changes you make to this notice if they are required to
> distribute ediprolog.el on ELPA. The master file I provide in the
> jurisdiction where I reside will retain the notice for the reason above.
If all authors of all GNU ELPA packages were to ask for special
treatment for their pet detail, I'd have given up on GNU ELPA
a long time ago.
Stefan
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2022-09-30 16:59 bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Markus Triska
` (4 preceding siblings ...)
2022-10-23 7:29 ` Markus Triska
@ 2024-01-10 10:54 ` Stefan Kangas
2024-01-10 22:11 ` Markus Triska
5 siblings, 1 reply; 35+ messages in thread
From: Stefan Kangas @ 2024-01-10 10:54 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196-done
Markus Triska <triska@metalevel.at> writes:
> ediprolog 2.2 is now available from:
>
> https://www.metalevel.at/ediprolog/ediprolog.el
>
> New in this version:
>
> * handle answers of recent Scryer Prolog versions
> * faithful processing of multiline queries when using Scryer Prolog
> * improved compatibility with older Emacs versions
>
> Project page:
>
> https://www.metalevel.at/ediprolog/
>
> Video demonstration:
>
> https://www.metalevel.at/prolog/videos/ediprolog
>
> For completeness, I also include a copy of the source code below.
>
> Could you please upload the new release to ELPA?
>
> Thank you a lot!
> Markus
It seems like ediprolog 2.2 was uploaded to GNU ELPA on 2022-Oct-26.
Belayed congratulations on the new release.
I'm consequently closing this particular bug report. Please let me know
if that doesn't make sense for some reason and we can reopen.
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2024-01-10 10:54 ` bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Stefan Kangas
@ 2024-01-10 22:11 ` Markus Triska
2024-01-10 23:18 ` Stefan Kangas
0 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2024-01-10 22:11 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 58196-done
Stefan Kangas <stefankangas@gmail.com> writes:
> It seems like ediprolog 2.2 was uploaded to GNU ELPA on 2022-Oct-26.
> Belayed congratulations on the new release.
Thank you!
> I'm consequently closing this particular bug report. Please let me know
> if that doesn't make sense for some reason and we can reopen.
Several issues I mentioned in this thread still persist. For example,
the page is not formatted as intended, and the image is not
shown. Please see the discussion in this thread for more information.
Thank you and all the best,
Markus
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2024-01-10 22:11 ` Markus Triska
@ 2024-01-10 23:18 ` Stefan Kangas
2024-01-14 7:40 ` Markus Triska
0 siblings, 1 reply; 35+ messages in thread
From: Stefan Kangas @ 2024-01-10 23:18 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196-done
Markus Triska <triska@metalevel.at> writes:
>> I'm consequently closing this particular bug report. Please let me know
>> if that doesn't make sense for some reason and we can reopen.
>
> Several issues I mentioned in this thread still persist. For example,
> the page is not formatted as intended, and the image is not
> shown. Please see the discussion in this thread for more information.
Thanks. I'm concerned that those issues will get lost in the noise in
this bug, which is currently titled "27.0.50; ediprolog 2.2: Please
upload the new version to ELPA". For boring reasons, including
limitations in debbugs, it's not easy for me to change the title.
Does it make more sense to open new bugs to track those issues (thereby
making them more visible), or should we simply reopen this one?
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2024-01-10 23:18 ` Stefan Kangas
@ 2024-01-14 7:40 ` Markus Triska
2024-01-14 10:17 ` Stefan Kangas
0 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2024-01-14 7:40 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 58196-done
Stefan Kangas <stefankangas@gmail.com> writes:
> Does it make more sense to open new bugs to track those issues (thereby
> making them more visible), or should we simply reopen this one?
Personally, I would suggest you reopen this issue until you are certain
about how to best proceed: In this way, the mentioned remaining problems
are not forgotten, and I do not unnecessarily open more issues.
Thank you and all the best,
Markus
^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA
2024-01-14 7:40 ` Markus Triska
@ 2024-01-14 10:17 ` Stefan Kangas
0 siblings, 0 replies; 35+ messages in thread
From: Stefan Kangas @ 2024-01-14 10:17 UTC (permalink / raw)
To: Markus Triska; +Cc: 58196
reopen 58196
thanks
Markus Triska <triska@metalevel.at> writes:
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Does it make more sense to open new bugs to track those issues (thereby
>> making them more visible), or should we simply reopen this one?
>
> Personally, I would suggest you reopen this issue until you are certain
> about how to best proceed: In this way, the mentioned remaining problems
> are not forgotten, and I do not unnecessarily open more issues.
Done.
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2024-01-14 10:17 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-09-30 16:59 bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Markus Triska
2022-10-01 12:56 ` Lars Ingebrigtsen
2022-10-01 14:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-01 17:01 ` Markus Triska
2022-10-01 18:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-02 19:49 ` Markus Triska
2022-10-02 20:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-02 20:24 ` Markus Triska
2022-10-02 21:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-03 0:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-18 14:34 ` bug#58196: Trivial update to ediprolog Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-26 13:26 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-26 13:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-27 21:11 ` Markus Triska
2022-10-28 2:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 3:06 ` Stefan Kangas
2022-10-28 3:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 6:35 ` Eli Zaretskii
2022-10-28 12:37 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 3:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 16:49 ` Markus Triska
2022-10-28 18:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 20:01 ` Stefan Kangas
2022-10-28 20:20 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-28 20:51 ` Stefan Kangas
2022-10-28 21:54 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-22 16:20 ` Markus Triska
2022-10-22 16:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-23 7:29 ` Markus Triska
2022-10-25 19:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 10:54 ` bug#58196: 27.0.50; ediprolog 2.2: Please upload the new version to ELPA Stefan Kangas
2024-01-10 22:11 ` Markus Triska
2024-01-10 23:18 ` Stefan Kangas
2024-01-14 7:40 ` Markus Triska
2024-01-14 10:17 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).