Re: [O] [RFC] Change visibility for bracket links
Clément Pit--Claudel writes: > On 2016-10-07 22:38, Adam Porter wrote: >> I understand the motivation for making this change, but I respectfully >> request that this be made configurable. I much prefer the "clean" links >> without visible brackets, and adding them would seem like a regression >> to me. I'm guessing that many current Org users would also prefer to >> keep the brackets invisible. > > Adam, what do you think of my earlier suggestion (displaying the > brackets when the pointer is on them, hiding them otherwise? (In the > style of prettify-symbols-mode with unprettify-symbol-at-point) > I don't particularly care whether the brackets are shown or not, but I dislike things that change the visual appearance as you roll over them. The web is full of such things and they drive me bananas: you are trying to read something and you roll over something in the text that changes its appearance, possibly shifting the text that you are reading and leaving you to chase it around the page - good bye, concentration. Even if you do it by just switching visibility on the brackets, it's distracting when you are reading; it might be helpful when composing but I'm not convinced even for that. If this proposal is considered at all, *please* make it optional. My 2 cents. Thanks! -- Nick
Re: [O] [RFC] Change visibility for bracket links
On 2016-10-10 10:17, Nick Dokos wrote: > Clément Pit--Claudel writes: > >> On 2016-10-07 22:38, Adam Porter wrote: >>> I understand the motivation for making this change, but I respectfully >>> request that this be made configurable. I much prefer the "clean" links >>> without visible brackets, and adding them would seem like a regression >>> to me. I'm guessing that many current Org users would also prefer to >>> keep the brackets invisible. >> >> Adam, what do you think of my earlier suggestion (displaying the >> brackets when the pointer is on them, hiding them otherwise? (In the >> style of prettify-symbols-mode with unprettify-symbol-at-point) >> > > I don't particularly care whether the brackets are shown or not, but I > dislike things that change the visual appearance as you roll over > them. Note that by pointer I meant point, not mouse; IOW, pointing on something with your mouse would not change anything display-wise. I'm not sure what you meant by roll-over. > The web is full of such things and they drive me bananas: you > are trying to read something and you roll over something in the text > that changes its appearance, possibly shifting the text that you are > reading and leaving you to chase it around the page - good bye, > concentration. Even if you do it by just switching visibility on the > brackets, it's distracting when you are reading; it might be helpful > when composing but I'm not convinced even for that. Agreed. I'd be curious to get feedback from users of prettify-symbols-mode, too. And to know whether your objections apply as strongly to just revealing the brackets when the point is on them (not when they are being moused over) Cheers, Clément. signature.asc Description: OpenPGP digital signature
Re: [O] [RFC] Change visibility for bracket links
Clément Pit--Claudel writes: > On 2016-10-10 10:17, Nick Dokos wrote: >> Clément Pit--Claudel writes: >> >>> On 2016-10-07 22:38, Adam Porter wrote: I understand the motivation for making this change, but I respectfully request that this be made configurable. I much prefer the "clean" links without visible brackets, and adding them would seem like a regression to me. I'm guessing that many current Org users would also prefer to keep the brackets invisible. >>> >>> Adam, what do you think of my earlier suggestion (displaying the >>> brackets when the pointer is on them, hiding them otherwise? (In the >>> style of prettify-symbols-mode with unprettify-symbol-at-point) >>> >> >> I don't particularly care whether the brackets are shown or not, but I >> dislike things that change the visual appearance as you roll over >> them. > > Note that by pointer I meant point, not mouse; IOW, pointing on > something with your mouse would not change anything display-wise. > I'm not sure what you meant by roll-over. > Either mouse-over or "point-over" (to coin a phrase): changing the visual appearance "explosively" is bad IMO. Subtler changes might be more acceptable but I think it would require some research and user-customizable behaviour to satisfy different needs - in short, I'm not sure it's worth it but as long as I can turn it off, I'm OK with it: there are plenty of things in org that I've never used, in some cases consciously, in others because of ignorance, but if somebody finds them useful and they are not tripping me up constantly, their existence does not bother me. >> The web is full of such things and they drive me bananas: you >> are trying to read something and you roll over something in the text >> that changes its appearance, possibly shifting the text that you are >> reading and leaving you to chase it around the page - good bye, >> concentration. Even if you do it by just switching visibility on the >> brackets, it's distracting when you are reading; it might be helpful >> when composing but I'm not convinced even for that. > > Agreed. I'd be curious to get feedback from users of > prettify-symbols-mode, too. And to know whether your objections apply > as strongly to just revealing the brackets when the point is on them > (not when they are being moused over) > I don't think that's any different: using emacs on the console only allows "point-over" but if the mechanism is distracting, then I want to be able to turn it off there too. -- Nick
[O] Bug: babel can't locate psql [8.2.10 (release_8.2.10 @ /Applications/Emacs.app/Contents/Resources/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-mode mailing list.
Executing a block of psql produces the error: "/bin/bash: psql:
command not found".
Bash is able to find psql. So is M-: (executable-find "psql"). I
have a brew-installed psql in the standard brew-installed location for
my computer, at /usr/local/bin/psql. As far as I can tell, the
location of psql is hard-coded into ob-sql.el and is not configurable.
The command that ob-sql logs in the *Messages* buffer works in an
emacs shell session. But that, of course, is not the point.
Emacs : GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21)
of 2015-04-10 on builder10-9.porkrind.org
Package: Org-mode version 8.2.10 (release_8.2.10 @
/Applications/Emacs.app/Contents/Resources/lisp/org/)
current state:
==
(setq
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
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-after-todo-state-change-hook '(org-clock-out-if-current)
org-from-is-user-regexp "\\"
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 '(#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook org-show-block-all
append
local]
5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-hide-inline-tasks org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el"))
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-babel-load-languages '((sql . t))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
)
Re: [O] Bug: babel can't locate psql [8.2.10 (release_8.2.10 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Aloha Barbara, Barbara Shirtcliff writes: > 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-mode mailing list. > > > Executing a block of psql produces the error: "/bin/bash: psql: > command not found". > > Bash is able to find psql. So is M-: (executable-find "psql"). I > have a brew-installed psql in the standard brew-installed location for > my computer, at /usr/local/bin/psql. As far as I can tell, the > location of psql is hard-coded into ob-sql.el and is not configurable. > > The command that ob-sql logs in the *Messages* buffer works in an > emacs shell session. But that, of course, is not the point. Perhaps the exec-path-from-shell package would help in this instance? hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Problem with python session
I am not sure it makes sense to change anything for this. There is different behavior with scripts and the interpreter independently of org-mode, e.g. with python -i: >>> for i in range(3): ... print(i) ... i File "", line 3 i ^ SyntaxError: invalid syntax Vanilla python sessions are kind of maddening. These seemingly identical blocks are different, i.e. one works and one doesn't! Spoiler alert, they are not identical. #+BEGIN_SRC python :results output org drawer :session for i in range(3): for j in range(3): pass print(i) #+END_SRC #+RESULTS: :RESULTS: ... File "", line 3 ^ IndentationError: expected an indented block File "", line 1 pass ^ IndentationError: unexpected indent >>> File "", line 1 print(i) ^ IndentationError: unexpected indent :END: This block which works has one space at the beginning of the blank lines. #+BEGIN_SRC python :results output org drawer :session for i in range(3): for j in range(3): pass print(i) #+END_SRC #+RESULTS: :RESULTS: ... ... ... ... ... 0 1 2 :END: This kind of error would be hard to reliably fix IMHO since it would rely on replacing blank lines with at least a space, and adding a blank line after indentation changes, except they can not be empty, they need at least a space in them. It is not clear that is a good idea. Maybe a test that replaces "\n" with "\n \n" might clear it up, but might also add a bunch of the ... >>> characters in the output? This is not an issue with python scripts or ipython, however. Nicolas Goaziou writes: > Hello, > > William Henney writes: > >> I can reproduce your problem. This is (arguably) a bug in ob-python when >> using the vanilla python interpreter together with the :session argument. >> You can work around it by putting a blank line after the for-loop in your >> second code block. >> >> I say that it is arguable that this is a bug or not since you would have >> exactly the same error if you were to literally type your code block in at >> the python interactive prompt. That is, you have to give a second newline >> in order to close the loop and return to the top-level prompt. However, it >> is admittedly confusing to have different behavior with and without the >> ":session" argument. > > Thank you for the analysis. Would you have a suggestion on how to > improve the situation? > > Regards, -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
