Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Eric S Fraga writes: > It would be great, for others that may be interested, if you could post > your solution to this list. Here's an alternative way to achieve this with today's master. --- a/lisp/org-table.el 2019-02-21 21:28:34.0 +1300 +++ b/lisp/org-table.el 2019-02-21 22:17:04.0 +1300 @@ -3945,7 +3945,8 @@ (when (org-table--shrunk-field) (push column shrunk))) (nreverse shrunk -(defun org-table--make-shrinking-overlay (start end display field pre) +(defun org-table--make-shrinking-overlay (start end display field + pre indicator) "Create an overlay to shrink text between START and END. Use string DISPLAY instead of the real text between the two @@ -3955,8 +3956,9 @@ When optional argument PRE is non-nil, assume the overlay is located at the beginning of the field, and prepend -`org-table-separator-space' to it. Otherwise, concatenate -`org-table-shrunk-column-indicator' at its end. +`org-table-separator-space' to it. Otherwise, concatenate +optional string INDICATOR at its end. If INDICATOR is omitted or +nil, `org-table-shrunk-column-indicator' is used instead. Return the overlay." (let ((show-before-edit @@ -3965,7 +3967,8 @@ ;; same column. (mapc #'delete-overlay (cdr (overlay-get o 'org-table-column-overlays) - (o (make-overlay start end))) + (o (make-overlay start end)) + (indicator (or indicator org-table-shrunk-column-indicator))) (overlay-put o 'insert-behind-hooks (list show-before-edit)) (overlay-put o 'insert-in-front-hooks (list show-before-edit)) (overlay-put o 'modification-hooks (list show-before-edit)) @@ -3975,7 +3978,7 @@ ;; See `org-table-overlay-coordinates'. (overlay-put o 'priority 1) (let ((d (if pre (concat org-table-separator-space display) - (concat display org-table-shrunk-column-indicator + (concat display indicator (org-overlay-display o d 'org-table t)) o)) @@ -4014,10 +4017,11 @@ ((org-table--shrunk-field) nil) ;already shrunk ((= 0 width);shrink to one character (list (org-table--make-shrinking-overlay - start end "" (if (eq 'hline contents) "" contents + start end "" (if (eq 'hline contents) "" contents) + nil org-table-shrunk-column-indicator))) ((eq contents 'hline) (list (org-table--make-shrinking-overlay - start end (make-string (1+ width) ?-) ""))) + start end (make-string (1+ width) ?-) "" nil "-"))) ((equal contents "");no contents to hide (list (let ((w (org-string-width (buffer-substring start end))) @@ -4026,8 +4030,11 @@ (full (+ 2 width))) (if (<= w full) (org-table--make-shrinking-overlay - (1- end) end (make-string (- full w) ?\s) "") -(org-table--make-shrinking-overlay (- end (- w full) 1) end "" "") + (1- end) end (make-string (- full w) ?\s) + "" nil org-table-separator-space) +(org-table--make-shrinking-overlay + (- end (- w full) 1) end "" "" + nil org-table-separator-space) (t ;; If the field is not empty, display exactly WIDTH characters. ;; It can mean to partly hide the field, or extend it with virtual @@ -4048,7 +4055,8 @@ (let ((pre (and (> lead 0) (org-table--make-shrinking-overlay -start (+ start lead) "" contents t))) +start (+ start lead) "" contents + t org-table-shrunk-column-indicator))) (post (org-table--make-shrinking-overlay ;; Find cut location so that WIDTH characters are @@ -4069,7 +4077,7 @@ ((pred (< width)) (setq upper mean)) (_ (setq lower mean) upper)) - end "" contents))) + end "" contents nil org-table-shrunk-column-indicator))) (if pre (list pre post) (list post ;; Contents fit it WIDTH characters. First compute number of ;; white spaces needed on each side of contents, then expand or @@ -4091,24 +4099,28 @@ ((or (guard (= lead 0)) (pred (= before))) nil) ((pred (< before)) (org-table--make-shrinking-overlay - start (+ start (- lead before)) "" contents t)) + start (+ start (- lead before)) + "" contents t org-table-separator-space)) (_ (org-table--make-shrinking-overlay start (1+ start) (make-string (- before (1- lead)) ?\s) - contents t + contents t org-table-separator-space (post (pcase (1- trail) ((pred (=
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Nicolas Goaziou writes: > Anyway, I changed the algorithm, so shrinking should now obey to > alignment. By the way, I think this change may have introduced a new bug. When the specified column width is one or two characters wider than the longest cell in the column (26 and 27 char in the example below), the shrunk column indicator and right-hand table borders do not draw correctly. For example, shrink the following with C-c TAB: | <26> | | this cell is 25 char long | | | and you get: | <26> …| | this cell is 25 char long …| | | One char wider gives: | <27> …| | this cell is 25 char long …| | … org-version -> org-9.2.1-252-g3a106a
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Eric S Fraga writes: > On Tuesday, 19 Feb 2019 at 03:16, Nick Helm wrote: > > [...] > >> Great, got it sorted now. Thanks again for your time. > > It would be great, for others that may be interested, if you could post > your solution to this list. Sure, patch below. It's a bit crude, but it works for 9.2.1-dist (needs changes for today's master): --- a/lisp/org-table.el 2019-02-19 14:06:13.0 +1300 +++ b/lisp/org-table.el 2019-02-19 14:07:58.0 +1300 @@ -3938,7 +3938,7 @@ (list (org-table--make-shrinking-overlay start end (concat (make-string (max 0 (1+ width)) ?-) - org-table-shrunk-column-indicator) + "-") ""))) (t ;; If the field is not empty, consider using two overlays: one for @@ -3962,7 +3962,7 @@ ;; white space characters to the right overlay. (org-table--make-shrinking-overlay (1- end) end (concat (make-string (- width w) ?\s) - org-table-shrunk-column-indicator) + " ") contents) ;; Find cut location so that WIDTH characters are visible. (org-table--make-shrinking-overlay @@ -3979,7 +3979,10 @@ ((pred (< width)) (setq upper mean)) (_ (setq lower mean) upper)) -end org-table-shrunk-column-indicator contents) +end (if (> (length contents) width) + org-table-shrunk-column-indicator + " ") + contents) (delq nil (list pre-overlay post-overlay)) (defun org-table--read-column-selection (select max)
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Nicolas Goaziou writes: > Nick Helm writes: > >> Could you tell me what functions govern this feature? > > You may want to have a look into `org-table--shrink-field' and > `org-table--make-shrinking-overlay'. Great, got it sorted now. Thanks again for your time.
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Nicolas Goaziou writes: > Nick Helm writes: > >> But, the rest of the time, can't the indicator serve both purposes - >> indicate a shrunken column and the presence of truncated cells - when it >> is limited to places where text is hidden? > > I find it confusing -- you may actually miss the information that the > current column is shrunk -- and not terribly useful. In particular, you > can tweak the column width, and, more importantly, expand, and shrink > again, the column quickly. I guess we use org in quite different ways. >> If I can't convince you to restore the default, would you consider >> adding the previous behaviour as a configurable option? > > I'm not even convinced there's a real use-case for this behaviour that > cannot be solved otherwise. Therefore, I don't think such a variable is > needed. That's a shame. Could you tell me what functions govern this feature?
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Nicolas Goaziou writes: > Anyway, I changed the algorithm, so shrinking should now obey to > alignment. Thank you for the feedback. Thank you – this is a welcome improvement. >> | <5> …| >> | one …| >> | one …| >> >> This is misleading - cell 3 contains no additional content yet the >> indicator says it does. It's also ambiguous - it's impossible to >> determine whether cell 2 or 3 contains the longer field. >> >> Compare with this, where such information is clearly conveyed: >> >> | <5> | >> | one …| >> | one | > > This is not misleading. The "…" characters means the /column/ as a whole > is shrunk, not that an individual field is. OK, I see the value of indicating the column state like this when it's shrunk to a width of 1 character and no cell content is visible (which, BTW, is an great new feature). But, the rest of the time, can't the indicator serve both purposes - indicate a shrunken column and the presence of truncated cells - when it is limited to places where text is hidden? Granted, it might be less visible and it wouldn't appear on cells that truncate only whitespace when shrunk, but IMO those are minor downsides. >> Has this been removed from 9.2 as well? > > Yes, it has. If I can't convince you to restore the default, would you consider adding the previous behaviour as a configurable option? Nick
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Thank you for your response. Nicolas Goaziou writes: > Nick Helm writes: >> >> The column is no longer right aligned. > > This is by design, so you can often edit the field without expanding the > column. I'm not sure I follow. Are you saying the ability align cell contents in a shrunk column has been purposefully removed from 9.2? If that's the case, it's a significant loss of functionality. This would mean, for instance, that it's no longer possible to format financial data with a uniform column width. >> In the last table above, continuation / truncation / shrunk cell >> characters (…) display even though the column is the full specified >> width (40 char in this case) and no cell text is truncated. I expect >> continuation to only show when text is actually truncated. > > I think this is a matter of taste. > > Of course, this is slightly more informative, but I prefer a more > visible "…" character. It might be confusing otherwise, e.g., if you > edit a narrow column, which suddenly expands because a very large column > below. The choice of continuation character is indeed personal preference, but the character's presence on non-truncated cells is not. It's misleading and ambiguous. Let me try to illustrate with another example. If you shrink this table with C-c TAB: | <5> | | one two | | one | you get the following: | <5> …| | one …| | one …| This is misleading - cell 3 contains no additional content yet the indicator says it does. It's also ambiguous - it's impossible to determine whether cell 2 or 3 contains the longer field. Compare with this, where such information is clearly conveyed: | <5> | | one …| | one | I wouldn't describe this difference as a matter of taste. This is a feature that previously existed (substitute "=>" for "…" in the table above and you have the result in 9.1). Has this been removed from 9.2 as well? Nick
[O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. I recently installed Org 9.2.1 and encountered a few bugs / issues with the new implementaion of Org tables: 1. columns do not correctly align when using a combined alignment and width cookie 2. shrinking to a specified column width indicates continuation / truncation where none exists 3. editing a cell narrower than its specified column width unnecessarily expands the entire column. Several "Invalid function: org-table-with-shrunk-field" errors also show up in *Messages* during these operations. (it's a macro) Recipes: Emacs -Q (org-version) -> "9.2.1" 1. Create a new table: | one | | two is a longer cell | Add a right alignment override and realign with C-c C-c: | | | one | | two is a longer cell | Specify a column width: | | | one | | two is a longer cell | and shrink to size with C-c TAB: |…| | one …| | two is a longer cell…| The column is no longer right aligned. 2. In the last table above, continuation / truncation / shrunk cell characters (…) display even though the column is the full specified width (40 char in this case) and no cell text is truncated. I expect continuation to only show when text is actually truncated. In the example above, something like this (mockup): | | | one | | two is a longer cell | And in the case of a narrower column, where a cell contains truncated / hidden text, something like this (mockup): || | one | | two is a longer…| 3. Create a new table and shrink to a specified column width with C-u C-c TAB: | <15> …| | one…| | two is a longer…| Move point to the second cell and delete the "e" in "one": | <15> | | on | | two is a longer cell | The entire column expands, even though this action is not necessary to perform the edit (annoying if the column contains other cells with text longer than the window width). Emacs : GNU Emacs 26.1 (build 1, x86_64-apple-darwin18.2.0, Carbon Version 158 AppKit 1671.2) of 2019-02-08 Package: Org mode version 9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
On Sun, 29 Apr 2018 at 23:05:20 +1200, Bastien wrote: > I may be wrong in thinking disabling this will cause trouble to > many users. Let's just take a moment to see what users think. I vote to drop "
Re: [O] Running org-mode (and emacs) inside the Web browser ?
On Fri, 27 Oct 2017 at 17:49:53 +0200, Olivier Berger wrote: > I've had this crazy idea to try and "port" emacs to the Web browser > (using some tools like [[https://browsix.org/][browsix]]), for the > purpose of running org-mode inside a browser tab. > > Anyone having had the same idea yet ? A few months ago, a browser-based version of Spacemacs appeared. It's no longer up, but this post mentions how it was done and links to the dev repos. https://www.reddit.com/r/emacs/comments/66locu/try_spacemacs_directly_in_the_browser/ Might be useful.
Re: [O] How to get the eacute above the e in saute or Saute?
On Fri, 13 Oct 2017 at 05:58:20 +1300, Sharon Kimble wrote: > Ok, thanks, that works, but how can I assign a keypress to it as I need > to use it very often, several times each day. Plus I've got a backlog to > work through too. If you only need that one character, you could temporarily assign a convenient key binding. Something like this perhaps? (global-set-key (kbd "S-C-e") [233])
Re: [O] Bug: Deleting region in table [9.0.8 (9.0.8-dist @ /Users/nick/.emacs.d/lisp/org/)]
Hi Nicholas, I see the fix for this bug (commit 91c68865c64422028faca96b7ff03541e7cf) was merged for org 9.0.10. However, I installed 9.0.10 this morning and the bug still occurs. Apologies if I am missing something. With thanks, Nick H On Thu, Aug 17 2017, Nicolas Goaziou wrote: > Nick Helm <n...@tenpoint.co.nz> writes: > >> Deleting a region within an org table causes point to jump. >> >> Recipe: >> >> Emacs -Q >> org-mode >> >> ;make a table >> | this is a simple | table | >> >> double-click "simple" ;place region over a word >> >> >> With the last command, I expect the word "simple" to be deleted, the >> right-hand "|" separator (and following column) to close up six chars, >> and point to end up to the right of "a ". >> >> Note however that point winds up in the middle of the next column over >> the word "table". Or, more precisely, one screen column to the left of >> where it started. An additional space is also inserted in the first >> column. >> >> I had a look at org.el and I think this occurs because the function >> `org-delete-backward-char' (which my system calls by default to delete >> text in a table) is unaware of the region and treats the case above as a >> single char backwards delete. > > Good catch! > > Fixed. Thank you for the report and the analysis.
[O] Bug: Deleting region in table [9.0.8 (9.0.8-dist @ /Users/nick/.emacs.d/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Deleting a region within an org table causes point to jump.
Recipe:
Emacs -Q
org-mode
;make a table
| this is a simple | table |
double-click "simple" ;place region over a word
With the last command, I expect the word "simple" to be deleted, the
right-hand "|" separator (and following column) to close up six chars,
and point to end up to the right of "a ".
Note however that point winds up in the middle of the next column over
the word "table". Or, more precisely, one screen column to the left of
where it started. An additional space is also inserted in the first
column.
I had a look at org.el and I think this occurs because the function
`org-delete-backward-char' (which my system calls by default to delete
text in a table) is unaware of the region and treats the case above as a
single char backwards delete.
Tweaking the function like this seems to help.
--- a/src/org.el2017-06-06 03:25:46.0 +1200
+++ b/src/org.el2017-08-13 15:52:32.0 +1200
@@ -20243,6 +20243,7 @@
(org-check-before-invisible-edit 'delete-backward)
(if (and (org-at-table-p)
(eq N 1)
+(not (org-region-active-p))
(string-match "|" (buffer-substring (point-at-bol) (point)))
(looking-at ".*?|"))
(let ((pos (point))
The situation is the same with org 9.0.9 and master.
Emacs : GNU Emacs 25.2.1 (x86_64-apple-darwin16.7.0, Carbon Version 157 AppKit
1504.83)
of 2017-08-12
Package: Org mode version 9.0.8 (9.0.8-dist @ /Users/nick/.emacs.d/lisp/org/)
current state:
==
(setq
org-export-backends '(ascii html latex odt)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-adapt-indentation nil
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-confirm-shell-link-function 'yes-or-no-p
org-image-actual-width 150
org-startup-align-all-tables t
org-startup-folded nil
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-block-all append
local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
(lambda nil
(face-remap-add-relative (quote font-lock-comment-face)
(quote org-comment))
(font-lock-add-keywords nil
(quote (("^\\s-*\\([+-]\\|[0-9]+\\.\\)\\s-" 1 (quote
org-list-bullet)
)
)
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-fontify-quote-and-verse-blocks t
org-export-before-parsing-hook '((lambda (x) (setq org-odt-styles-dir
nh-emacs-etc)))
org-catch-invisible-edits 'show
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("id" :follow org-id-open)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete
org-bbdb-complete-link :store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs")
("doi" :follow org--open-doi-link) ("elisp" :follow
org--open-elisp-link)
("file" :complete org-file-complete-link)
("ftp" :follow (lambda (path) (browse-url (concat "ftp:"
