bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

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

typing directly into a cells in tables does not change the size of the
cell when table-fixed-width-mode is set; however, yanking and killing
within a cell does change the size of the cell.


In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu)
 of 2014-06-06 on barber, modified by Debian
System Description:     Debian 7.0 GNU/Linux wheezy/testing

Configured using:
 `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var/lib' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lis\
p:/usr/share/emacs/site-lisp'
 '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=no'
 '--without-gconf' '--without-gsettings' 'build_alias=x86_64-linux-gnu'
 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
 -Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  semantic-minor-modes-format: ((:eval (if (or
semantic-highlight-edits-mode semantic-show-unmatched-syntax-mode)  S)))
  desktop-save-mode: t
  winner-mode: t
  savehist-mode: t
  electric-pair-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  shell-dirtrack-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
mule-util cal-move repeat table two-column tabify org-table debug
boxquote apropos rect image-file org-clock tutorial org-element finder
finder-inf lisp-mnt help-mode misearch multi-isearch jka-compr
browse-kill-ring dabbrev ibuf-ext ibuffer org-wl org-w3m org-vm
org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html org-exp
ob-exp org-exp-blocks org-agenda org-info org-gnus gnus-util org-docview
org-bibtex bibtex org-bbdb org ob-tangle ob-ref ob-lob ob-table
org-footnote org-src ob-comint ob-keys org-pcomplete org-list org-faces
org-entities noutline outline org-version ob-emacs-lisp ob org-compat
org-macs ob-eval org-loaddefs find-func cal-menu calendar cal-loaddefs
server vc-git bookmark pp saveplace desktop dired-details+ dired
dired-details uniquify winner csv-mode-autoloads
dired-details+-autoloads dired-details-autoloads dirtree-autoloads
hide-lines-autoloads igrep-autoloads nav-autoloads pager-autoloads
pager-default-keybindings-autoloads revive+-autoloads revive-autoloads
tree-mode-autoloads w3-autoloads w3m-autoloads info web-autoloads
windata-autoloads workgroups2-autoloads package savehist cus-start
cus-load woman man electric paren delsel debian-el debian-el-loaddefs
w3m-load slime-autoloads 50magit ido ess-toolbar ess-mouse mouseme
browse-url ess-menu ess-swv ess-noweb ess-noweb-font-lock-mode
ess-bugs-l essd-els ess-sas-d ess-sas-l ess-sas-a shell pcomplete
ess-sta-d ess-sta-l cc-vars cc-defs make-regexp ess-sp6-d ess-sp3-d
ess-julia ess-r-d ess-tracebug format-spec ess-roxy ess-help
ess-developer ess-r-args eldoc ess-s-l ess ess-inf ess-mode
ess-noweb-mode ess-utils ess-custom executable ess-compat ess-site
emacs-goodies-el emacs-goodies-custom emacs-goodies-loaddefs easy-mmode
ecb cl-macs warnings edmacro kmacro ecb-symboldef ecb-analyse
ecb-compatibility ecb-winman-support ecb-autogen autoload ecb-tod
ecb-cycle ecb-eshell ecb-help ecb-jde ecb-method-browser hideshow
ecb-semantic ecb-file-browser ecb-speedbar ecb-layout compile comint
regexp-opt ansi-color tool-bar ecb-create-layout ecb-compilation
ecb-common-browser time-date assoc speedbar sb-image dframe ecb-navigate
ecb-mode-line ecb-face tree-buffer ecb-upgrade ecb-cedet-wrapper
semantic/db-mode semantic/db-find semantic/db-ref semantic/analyze
semantic/sort semantic/scope semantic/analyze/fcn semantic/db gv
eieio-base semantic/format ezimage image semantic/tag-ls semantic/find
semantic/ctxt semantic/util-modes easymenu semantic/util semantic
semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp
byte-compile cconv mode-local cedet wid-edit ecb-util ring thingatpt
dpkg-dev-el dpkg-dev-el-loaddefs devhelp develock advice help-fns cl
cl-lib advice-preload ediff-hook vc-hooks lisp-float-type tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
multi-tty emacs)

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> typing directly into a cells in tables does not change the size of the
> cell when table-fixed-width-mode is set; however, yanking and killing
> within a cell does change the size of the cell.

(This bug report unfortunately got no response at the time.)

Do you have a recipe, starting from "emacs -Q", to reproduce this bug?

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

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

On 2020-12-04 12:29, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > typing directly into a cells in tables does not change the size of the
> > cell when table-fixed-width-mode is set; however, yanking and killing
> > within a cell does change the size of the cell.
>
> (This bug report unfortunately got no response at the time.)
>
> Do you have a recipe, starting from "emacs -Q", to reproduce this bug?

Yes. A form of this bug is reproducible in emacs-snapshot,
inconsistencies of mode's definition, so I'm providing a recipe for the
simplest case, tested in an October version of emacs-snapshot.

After opening a fresh emacs:

1) find an org-mode file
2) create an org-mode heading line just to show you're in org mode, eg
   * foo
3) M-x table-fixed-width-mode
4) Verify by evaluating table-fixed-width-mode and getting a 't' result
5) Create a table, using the defaults of M-x table-insert
6) C-c ' to edit the current table cell
7) Insert a string greater than the cell width. The expected behavior is
   "A word that is too long to fit in a cell is chopped into multiple
   lines". Note that is not the case within the cell editor pop-up
   buffer. Rather the cell width is expanded.
8) Save your cell-edit changes using C-c '. Note the persistence of the
   unexpected behavior.

My vague vague memory of the distant past when I submitted the bug
report was that the unexpected behavior was different, as described in
my initial report, but some form of that original bug remains, just now
it's more consistent, and behaves just as badly whether inserting or
yanking text into a cell.

At this point, since the behavior is consistent, a lazy way to 'fix' the
bug might be to just change the docstring...

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

>> > typing directly into a cells in tables does not change the size of the
>> > cell when table-fixed-width-mode is set; however, yanking and killing
>> > within a cell does change the size of the cell.
>>
>> (This bug report unfortunately got no response at the time.)
>>
>> Do you have a recipe, starting from "emacs -Q", to reproduce this bug?
>
> Yes. A form of this bug is reproducible in emacs-snapshot,
> inconsistencies of mode's definition, so I'm providing a recipe for the
> simplest case, tested in an October version of emacs-snapshot.
>
> After opening a fresh emacs:
>
> 1) find an org-mode file
> 2) create an org-mode heading line just to show you're in org mode, eg
>    * foo
> 3) M-x table-fixed-width-mode
> 4) Verify by evaluating table-fixed-width-mode and getting a 't' result
> 5) Create a table, using the defaults of M-x table-insert
> 6) C-c ' to edit the current table cell
> 7) Insert a string greater than the cell width. The expected behavior is
>    "A word that is too long to fit in a cell is chopped into multiple
>    lines". Note that is not the case within the cell editor pop-up
>    buffer. Rather the cell width is expanded.
> 8) Save your cell-edit changes using C-c '. Note the persistence of the
>    unexpected behavior.
>
> My vague vague memory of the distant past when I submitted the bug
> report was that the unexpected behavior was different, as described in
> my initial report, but some form of that original bug remains, just now
> it's more consistent, and behaves just as badly whether inserting or
> yanking text into a cell.

I see the same behaviour on the trunk.

> At this point, since the behavior is consistent, a lazy way to 'fix' the
> bug might be to just change the docstring...

Well, that would make table-fixed-width-mode useless?  (Which it is,
indeed, already.)

I tried debugging this, and while there is a bunch of code to handle the
fixed-width setting, I don't understand the code.
table--cell-insert-char always inserts non-space chars, no matter what
the setting is, and then table--measure-max-width measures the new
width, which makes table-with-cache-buffer widen the cell.

So I'm wondering -- has this ever worked?

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

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

On 2020-12-06 15:30, Lars Ingebrigtsen wrote:
> So I'm wondering -- has this ever worked?

Are you able to easily try it in emacs 24 or emacs 23? From the wording
of the original report, it seems that at one point the truncate-word
with the continuation symbol was working in some cases.

The mode in its current state isn't absolutely totally useless. It still
succeeds in maintaining cell width as long as all words are less than
the cell width. What I mean is that it successfully performs line wraps
when the line wrap doesn't call for truncation. Hmm. I'm not sure that
I'm describing it properly yet, so try this: after creating a table
using insert-table, enter the cell editor using C-c ' and type in a
bunch of space-delimited single alphanumeric characters. That case
successfully maintains the cell width and line wraps.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> On 2020-12-06 15:30, Lars Ingebrigtsen wrote:
>> So I'm wondering -- has this ever worked?
>
> Are you able to easily try it in emacs 24 or emacs 23? From the wording
> of the original report, it seems that at one point the truncate-word
> with the continuation symbol was working in some cases.

No, anything earlier than Emacs 26.1 refuses to build on my system,
unfortunately.

> The mode in its current state isn't absolutely totally useless. It still
> succeeds in maintaining cell width as long as all words are less than
> the cell width.

Sure, but the entire point of the mode is to chop too-long words, I
think?

----
Normally it should be nil for allowing automatic cell width expansion
that widens a cell when it is necessary.  When non-nil, typing in a
cell does not automatically expand the cell width.  A word that is too
long to fit in a cell is chopped into multiple lines.
----

And the code in table.el seems to bear that out -- there's tons of code
to insert/remove continuation characters when things are chopped, etc --
it's just that that code is never triggered.  I guess it was broken at
some point during one of the rewrites.

Hm...  perhaps a productive way to try to find what broke this would be
to try to do some bisection on the table.el file alone, and hope that
table.el doesn't rely too much on other things in Emacs that have also
changed over the years.  I'll give it a go.

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

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  perhaps a productive way to try to find what broke this would be
> to try to do some bisection on the table.el file alone, and hope that
> table.el doesn't rely too much on other things in Emacs that have also
> changed over the years.  I'll give it a go.

No dice.  I got back to 2010, and the bug seems to be present there,
too.  In versions before 2010, table.el doesn't work at all, because it
relies on Emacs internals that no longer exist in the current Emacs
version.

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

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

On 2020-12-07 15:06, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > Hm...  perhaps a productive way to try to find what broke this would be
> > to try to do some bisection on the table.el file alone, and hope that
> > table.el doesn't rely too much on other things in Emacs that have also
> > changed over the years.  I'll give it a go.
>
> No dice.  I got back to 2010, and the bug seems to be present there,
> too.  In versions before 2010, table.el doesn't work at all, because it
> relies on Emacs internals that no longer exist in the current Emacs
> version.

Seeing you invest time in this encouraged me to take a stab at it. I see
that even when table-fixed-width-mode is non-nil, within function
table--fill-region it for some reason evaluates nil! Because of this,
function table--fill-region-strictly is never used. If you manually set
the variable non-nil at the beginning of the function, then the feature
seems to work!

My guess then is that if we find where/how the value is being lost
internally, we will solve the problem. The package makes several uses of
temporary buffers, and the variable is set in the define-minor-mode
macro, so if the mode variable is buffer-local (it is isn't it?) then it
would get lost when using the temp buffer?


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

I think I have a fix, centered around adding two lines to function
table--update-cell. In the snippet below, the new lines are marked with
an arrow ; <--------


(defun table--update-cell (&optional now)
  "Update the table cell contents.
When the optional parameter NOW is nil it only sets up the update
timer.  If it is non-nil the function copies the contents of the cell
cache buffer into the designated cell in the table buffer."
  (if (null table-update-timer) nil
    (table--cancel-timer table-update-timer)
    (setq table-update-timer nil))
  (if (or (not now)
	  (and (boundp 'quail-converting)
	       quail-converting) ;; defer operation while current quail work is not finished.
	  (and (boundp 'quail-translating)
	       quail-translating))
      (setq table-update-timer
	    (table--set-timer table-time-before-update
			      (function table--update-cell)
			      'now))
    (save-current-buffer
      (set-buffer table-cell-buffer)
      (let ((cache-buffer (get-buffer-create table-cache-buffer-name))
	    (org-coord (table--get-coordinate))
            (fixed table-fixed-width-mode) ; <--------
	    (in-cell (equal (table--cell-to-coord (table--probe-cell))
			    (cons table-cell-info-lu-coordinate table-cell-info-rb-coordinate)))
	    rectangle)
	(set-buffer cache-buffer)
        (setq-local table-fixed-width-mode fixed) ; <---------
	(setq rectangle
	      (extract-rectangle
	       1
	       (table--goto-coordinate (cons table-cell-info-width (1- table-cell-info-height)))))
	(set-buffer table-cell-buffer)
	(delete-rectangle (table--goto-coordinate table-cell-info-lu-coordinate)
			  (table--goto-coordinate table-cell-info-rb-coordinate))
	(table--goto-coordinate table-cell-info-lu-coordinate)
	(table--insert-rectangle rectangle)
	(let* ((cell (table--probe-cell))) ; must probe again in case of wide characters
	  (table--put-cell-property cell)
	  (table--put-cell-justify-property cell table-cell-info-justify)
	  (table--put-cell-valign-property cell table-cell-info-valign))
	(table--goto-coordinate
	 (if in-cell
	     (table--transcoord-cache-to-table table-cell-cache-point-coordinate)
	   org-coord))))
    ;; simulate undo behavior under overwrite-mode
    (if (and overwrite-mode (not (eq buffer-undo-list t)))
	(setq buffer-undo-list (cons nil buffer-undo-list)))))


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> I think I have a fix, centered around adding two lines to function
> table--update-cell. In the snippet below, the new lines are marked with
> an arrow ; <--------

Yup; that fixes the problem for me, too, so I've now pushed it to Emacs
28.

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

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

Follow-up: The behavior of the table logic is different when not in an
org buffer. There seems to be confusion (possibly my confusion?) between
using table and org-table. In any event, the ability to mess up things
can itself be considered a bug.

Try this. In both an empty scratch buffer and an org buffer, perform M-x
table-insert. From within each table, press TAB in an attempt to
navigate table cells. It works only in the scratch buffer, and in the
org buffer, I get a message telling me "Use ‘C-c '’ to edit table.el
tables". In the scratch buffer, that is not necessary (and in fact is
undefined) , and you can edit the table directly. My fix (so far) works
only in the scratch buffer, not in the org buffer.

(TANGENT: Also, I see that when using the C-c ' method and canceling out
using C-c C-k, POINT is improperly restored to the beginning of the
table instead of the point at which C-c ' was invoked.)

When the table.el table is created in an org buffer, function
org-src--edit-element does the work, and I don't see it using any of the
code from table.el. This is asking for trouble in that any code
maintenance to table.el functionality (eg. any fix for this bug report)
needs to be done in two places, and in this case the code in each place
seems very different, so it really is double work.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

Hi Lars. I've been doing some more work on the bug and have a solution
for the secondary issue found, the one that I marked previously as
'tangent'. In that related bug, aborting from a table.el edit sets POINT
at the beginning of the table instead of where it was upon entry to the
edit session. The solution was simply to save and restore point. The
saving is done in function org-src--edit-element and the restore is
performed in function org-edit-src-abort. Here are the modified
functions with the two additional lines marked with arrows ; <------

(defun org-src--edit-element
    (datum name &optional initialize write-back contents remote)
  "Edit DATUM contents in a dedicated buffer NAME.

INITIALIZE is a function to call upon creating the buffer.

When WRITE-BACK is non-nil, assume contents will replace original
region.  Moreover, if it is a function, apply it in the edit
buffer, from point min, before returning the contents.

When CONTENTS is non-nil, display them in the edit buffer.
Otherwise, show DATUM contents as specified by
`org-src--contents-area'.

When REMOTE is non-nil, do not try to preserve point or mark when
moving from the edit area to the source.

Leave point in edit buffer."
  (setq org-src--saved-temp-window-config (current-window-configuration))
  (let* ((area (org-src--contents-area datum))
	 (beg (copy-marker (nth 0 area)))
	 (end (copy-marker (nth 1 area) t))
	 (old-edit-buffer (org-src--edit-buffer beg end))
         (fixed table-fixed-width-mode)
	 (contents (or contents (nth 2 area))))
    (if (and old-edit-buffer
	     (or (not org-src-ask-before-returning-to-edit-buffer)
		 (y-or-n-p "Return to existing edit buffer ([n] will revert changes)? ")))
	;; Move to existing buffer.
	(org-src-switch-to-buffer old-edit-buffer 'return)
      (setq-local org-src--return-point (point)) ; <-------
      ;; Discard old edit buffer.
      (when old-edit-buffer
	(with-current-buffer old-edit-buffer (org-src--remove-overlay))
	(kill-buffer old-edit-buffer))
      (let* ((org-mode-p (derived-mode-p 'org-mode))
	     (source-tab-width (if indent-tabs-mode tab-width 0))
	     (type (org-element-type datum))
	     (ind (org-with-wide-buffer
		   (goto-char (org-element-property :begin datum))
		   (org-get-indentation)))
	     (preserve-ind
	      (and (memq type '(example-block src-block))
		   (or (org-element-property :preserve-indent datum)
		       org-src-preserve-indentation)))
	     ;; Store relative positions of mark (if any) and point
	     ;; within the edited area.
	     (point-coordinates (and (not remote)
				     (org-src--coordinates (point) beg end)))
	     (mark-coordinates (and (not remote)
				    (org-region-active-p)
				    (let ((m (mark)))
				      (and (>= m beg) (>= end m)
					   (org-src--coordinates m beg end)))))
	     ;; Generate a new edit buffer.
	     (buffer (generate-new-buffer name))
	     ;; Add an overlay on top of source.
	     (overlay (org-src--make-source-overlay beg end buffer)))
	;; Switch to edit buffer.
	(org-src-switch-to-buffer buffer 'edit)
        (setq-local table-fixed-width-mode fixed)
	;; Insert contents.
	(insert contents)
	(remove-text-properties (point-min) (point-max)
				'(display nil invisible nil intangible nil))
	(unless preserve-ind (org-do-remove-indentation))
	(set-buffer-modified-p nil)
	(setq buffer-file-name nil)
	;; Initialize buffer.
	(when (functionp initialize)
	  (let ((org-inhibit-startup t))
	    (condition-case e
		(funcall initialize)
	      (error (message "Initialization fails with: %S"
			      (error-message-string e))))))
	;; Transmit buffer-local variables for exit function.  It must
	;; be done after initializing major mode, as this operation
	;; may reset them otherwise.
	(setq-local org-src--tab-width source-tab-width)
	(setq-local org-src--from-org-mode org-mode-p)
	(setq-local org-src--beg-marker beg)
	(setq-local org-src--end-marker end)
	(setq-local org-src--remote remote)
	(setq-local org-src--source-type type)
	(setq-local org-src--block-indentation ind)
	(setq-local org-src--preserve-indentation preserve-ind)
	(setq-local org-src--overlay overlay)
	(setq-local org-src--allow-write-back write-back)
	;; Start minor mode.
	(org-src-mode)
	;; Move mark and point in edit buffer to the corresponding
	;; location.
	(if remote
	    (progn
	      ;; Put point at first non read-only character after
	      ;; leading blank.
	      (goto-char
	       (or (text-property-any (point-min) (point-max) 'read-only nil)
		   (point-max)))
	      (skip-chars-forward " \r\t\n"))
	  ;; Set mark and point.
	  (when mark-coordinates
	    (org-src--goto-coordinates mark-coordinates (point-min) (point-max))
	    (push-mark (point) 'no-message t)
	    (setq deactivate-mark nil))
	  (org-src--goto-coordinates
	   point-coordinates (point-min) (point-max)))))))

(defun org-edit-src-abort ()
  "Abort editing of the src code and return to the Org buffer."
  (interactive)
  (let (org-src--allow-write-back)
    (org-edit-src-exit)
    (goto-char org-src--return-point)))  ; <-------

If you feel that this should be an independent bug report, I can do
that. Also, if after you test and verify / approve, should you want it
in diff format or anything else, let me know.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> Hi Lars. I've been doing some more work on the bug and have a solution
> for the secondary issue found, the one that I marked previously as
> 'tangent'. In that related bug, aborting from a table.el edit sets POINT
> at the beginning of the table instead of where it was upon entry to the
> edit session. The solution was simply to save and restore point. The
> saving is done in function org-src--edit-element and the restore is
> performed in function org-edit-src-abort. Here are the modified
> functions with the two additional lines marked with arrows ; <------

Could you send that as a patch instead?  It's easier to read.

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

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

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

On 2020-12-08 14:40, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > Hi Lars. I've been doing some more work on the bug and have a solution
> > for the secondary issue found, the one that I marked previously as
> > 'tangent'. In that related bug, aborting from a table.el edit sets POINT
> > at the beginning of the table instead of where it was upon entry to the
> > edit session. The solution was simply to save and restore point. The
> > saving is done in function org-src--edit-element and the restore is
> > performed in function org-edit-src-abort. Here are the modified
> > functions with the two additional lines marked with arrows ; <------
>
> Could you send that as a patch instead?  It's easier to read.
>

Attached.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[-- Attachment #2: org-src-18183.patch --]
[-- Type: text/x-diff, Size: 940 bytes --]

diff --git a/org-src.el b/org-src.el
index 7876dea..96ab8ad 100644
--- a/org-src.el
+++ b/org-src.el
@@ -479,6 +479,7 @@ Leave point in edit buffer."
 		 (y-or-n-p "Return to existing edit buffer ([n] will revert changes)? ")))
 	;; Move to existing buffer.
 	(org-src-switch-to-buffer old-edit-buffer 'return)
+      (setq-local org-src--return-point (point))
       ;; Discard old edit buffer.
       (when old-edit-buffer
 	(with-current-buffer old-edit-buffer (org-src--remove-overlay))
@@ -1106,7 +1107,9 @@ the area in the Org mode buffer."
 (defun org-edit-src-abort ()
   "Abort editing of the src code and return to the Org buffer."
   (interactive)
-  (let (org-src--allow-write-back) (org-edit-src-exit)))
+  (let (org-src--allow-write-back)
+    (org-edit-src-exit)
+    (goto-char org-src--return-point)))

 (defun org-edit-src-continue (e)
   "Unconditionally return to buffer editing area under point.

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

>> > Hi Lars. I've been doing some more work on the bug and have a solution
>> > for the secondary issue found, the one that I marked previously as
>> > 'tangent'. In that related bug, aborting from a table.el edit sets POINT
>> > at the beginning of the table instead of where it was upon entry to the
>> > edit session. The solution was simply to save and restore point. The
>> > saving is done in function org-src--edit-element and the restore is
>> > performed in function org-edit-src-abort. Here are the modified
>> > functions with the two additional lines marked with arrows ; <------
>>
>> Could you send that as a patch instead?  It's easier to read.
>
> Attached.

[...]

> +      (setq-local org-src--return-point (point))
>        ;; Discard old edit buffer.
>        (when old-edit-buffer
>  	(with-current-buffer old-edit-buffer (org-src--remove-overlay))
> @@ -1106,7 +1107,9 @@ the area in the Org mode buffer."
>  (defun org-edit-src-abort ()
>    "Abort editing of the src code and return to the Org buffer."
>    (interactive)
> -  (let (org-src--allow-write-back) (org-edit-src-exit)))
> +  (let (org-src--allow-write-back)
> +    (org-edit-src-exit)
> +    (goto-char org-src--return-point)))

I think this makes sense, but I'm not an org expert, so I've added
Michael to the Cc's.  Any comments?

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

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

> I think this makes sense, but I'm not an org expert, so I've added
> Michael to the Cc's.  Any comments?

Thanks for your trust, but I'm also not an org expert.

Best regards, Michael.

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> Hi Lars,
>
>> I think this makes sense, but I'm not an org expert, so I've added
>> Michael to the Cc's.  Any comments?
>
> Thanks for your trust, but I'm also not an org expert.

:-)

Sorry, I guess that's Bastien, then?

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

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Bastien]

Hi Lars,

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>> Hi Lars,
>>
>>> I think this makes sense, but I'm not an org expert, so I've added
>>> Michael to the Cc's.  Any comments?
>>
>> Thanks for your trust, but I'm also not an org expert.
>
> :-)
>
> Sorry, I guess that's Bastien, then?

thanks for the ping -- Boruch, could you send the relevant patch to
emacs-orgmode@gnu.org explaining what problem it fixes?

Also, table.el tables are not supposed to be handled by Org-mode,
so instead of M-x table-insert you should use M-x org-table-create.

In general, I'm not sure table-fixed-width-mode is supposed to work
nicely with org-mode.

Best,

-- 
 Bastien

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

On 2020-12-10 11:37, Bastien wrote:
> thanks for the ping -- Boruch, could you send the relevant patch to
> emacs-orgmode@gnu.org explaining what problem it fixes?
>
> Also, table.el tables are not supposed to be handled by Org-mode,


See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18183#37
... message  "Use ‘C-c '’ to edit table.el tables".


> so instead of M-x table-insert you should use M-x org-table-create.
>
> In general, I'm not sure table-fixed-width-mode is supposed to work
> nicely with org-mode.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Bastien]

Boruch Baum <boruch_baum@gmx.com> writes:

> See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18183#37
> ... message  "Use ‘C-c '’ to edit table.el tables".

In org-mode, I suggest you use org-mode tables.

-- 
 Bastien

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

On 2020-12-14 19:21, Bastien wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=18183#37
> > ... message  "Use ‘C-c '’ to edit table.el tables".
>
> In org-mode, I suggest you use org-mode tables.

That direct suggestion to me doesn't help emacs users in general. They
would need maybe for the message to be removed and documentation to be
made explicit on the change of support, or for table.el tables to
continue to receive the support it apparently had in the past. Either
way, another bug.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

Okay, I've looked through how org-mode performs its version of table
editing, and although it take it upon itself to edit table.el tables in
addition to org-tables, I haven't found any support for
table-fixed-width-mode.

Org mode does have a similar-sounding feature
`org-edit-fixed-width-region', but it doesn't seem at all related to
tables. From the docstring: "This must be a region where each line
starts with a colon followed by a space or a newline character."

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

On 2020-12-07 14:53, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > The mode in its current state isn't absolutely totally useless. It still
> > succeeds in maintaining cell width as long as all words are less than
> > the cell width.
>
> Sure, but the entire point of the mode is to chop too-long words, I
> think?

That's much of its value, yes. But it also serves to suppress cell
expansion in the other case, and instead to perform line-wrapping of the
cell.

> Hm...  perhaps a productive way to try to find what broke this would be
> to try to do some bisection on the table.el file alone, and hope that
> table.el doesn't rely too much on other things in Emacs that have also
> changed over the years.  I'll give it a go.

Thanks.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

My understanding is that at this point we have four outstanding problems:

1) We are both reporting that the bug is fixed when editing a table.el
   table outside or org-mode, *BUT* we are reporting conflicting results
   when using the patch in an org-mode C-c ' editing session: I'm
   reporting that the bug remains and you're reporting that the bug is
   fixed there also.

2) You do agree that in that the org-mode edit buffer loses the state of
   table-fixed-width-mode from the parent buffer, and needs to be
   manually set. This is a bug; it should remember its state.

3) We are both reporting another secondary bug that when
   table-fixed-width-mode is nil, an org-mode edit will incorrectly
   line-wrap small words, ie maintain fixed-width cells even though
   table-fixed-width-mode is nil.

4) We haven't committed the patch yet for the secondary bug that POINT
   was returning properly after an aborted org-mode edit session.

On 2020-12-09 12:20, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > Please clarify, because that is not my experience from my testing. True,
> > the org-mode editor does line wrap small words, but in my testing it
> > wasn't truncating long words with a continuation symbol.
>
> It did for me when I tested it yesterday?
>
> >>  I just tried editing a table with C-c ' and then switched on
> >> table-fixed-width-mode, and that seemed to work OK...
> >
> > For long words (with truncation and continuation character) or short
> > words (with line wrap) or both?
>
> Both.
>

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> My understanding is that at this point we have four outstanding problems:
>
> 1) We are both reporting that the bug is fixed when editing a table.el
>    table outside or org-mode, *BUT* we are reporting conflicting results
>    when using the patch in an org-mode C-c ' editing session: I'm
>    reporting that the bug remains and you're reporting that the bug is
>    fixed there also.

That's what I seemed to see when I tried it, but perhaps we're doing it
in different ways.  What's your recipe to reproduce the bug?

> 2) You do agree that in that the org-mode edit buffer loses the state of
>    table-fixed-width-mode from the parent buffer, and needs to be
>    manually set. This is a bug; it should remember its state.

I'm not sure -- the editing happens in a different buffer, and toggling
it just there might make sense.  But I have no opinion, really.

> 3) We are both reporting another secondary bug that when
>    table-fixed-width-mode is nil, an org-mode edit will incorrectly
>    line-wrap small words, ie maintain fixed-width cells even though
>    table-fixed-width-mode is nil.

That's not a bug -- table-fixed-width-mode is only about wrapping long
words, and should have no effect at all on short words, one way or
another.  (And it doesn't seem to have.)

> 4) We haven't committed the patch yet for the secondary bug that POINT
>    was returning properly after an aborted org-mode edit session.

I think I've forgotten what that bug was about.  :-)

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

bug#18183: 24.3; table-fixed-width-mode fails with kill/yank

[Boruch Baum]

On 2020-12-09 20:35, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > My understanding is that at this point we have four outstanding problems:
> >
> > 1) We are both reporting that the bug is fixed when editing a table.el
> >    table outside or org-mode, *BUT* we are reporting conflicting results
> >    when using the patch in an org-mode C-c ' editing session: I'm
> >    reporting that the bug remains and you're reporting that the bug is
> >    fixed there also.
>
> That's what I seemed to see when I tried it, but perhaps we're doing it
> in different ways.  What's your recipe to reproduce the bug?

The original recipe reported earlier in the thread.

> > 2) You do agree that in that the org-mode edit buffer loses the state of
> >    table-fixed-width-mode from the parent buffer, and needs to be
> >    manually set. This is a bug; it should remember its state.
>
> I'm not sure -- the editing happens in a different buffer, and toggling
> it just there might make sense.  But I have no opinion, really.

I'm opinionated. I don't want to need to repeatedly perform the
operation each time within a single emacs session that I return to edit
the same table.

> > 3) We are both reporting another secondary bug that when
> >    table-fixed-width-mode is nil, an org-mode edit will incorrectly
> >    line-wrap small words, ie maintain fixed-width cells even though
> >    table-fixed-width-mode is nil.
>
> That's not a bug -- table-fixed-width-mode is only about wrapping long
> words, and should have no effect at all on short words, one way or
> another.  (And it doesn't seem to have.)

From the docstring: "Cell width is fixed when this is non-nil. Normally
it should be nil for allowing automatic cell width expansion that widens
a cell when it is necessary...". The specific case of wrapping long
lines is just an example, and is mentioned to discuss the related
defcustom variable.

> > 4) We haven't committed the patch yet for the secondary bug that POINT
> >    was returning properly after an aborted org-mode edit session.
>
> I think I've forgotten what that bug was about.  :-)

That's what the thread is for! Hint: It was what you asked Michael and
Bastien to comment on...

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0