org-goto bug

2024-02-21 Thread Pan Xie

Hello

Just found a minor issue about the org-goto interface. When I set 
`org-goto-auto-isearch' as `t', the number keys should also be part of 
isearch, not treated as "digit argument". However, the current version 
(9.7-pre) of OrgMode I am using treat the number keys as digit argument 
in auto isearch mode.


I also find the solution: just pass `t' as second argument to 
`suppress-keymap', to make all number keys unbound in the keymap:


#+begin_src elisp
;; org-goto.el
(defun org-goto--set-map ()
  "Set the keymap `org-goto'."
  (setq org-goto-map
    (let ((map (make-sparse-keymap)))
      (let ((cmds '(isearch-forward isearch-backward kill-ring-save 
set-mark-command

                mouse-drag-region universal-argument org-occur)))
    (dolist (cmd cmds)
      (substitute-key-definition cmd cmd map global-map)))
      (suppress-keymap map t) ;; < 
pass t as second argument to fix the issue

      (org-defkey map "\C-m" 'org-goto-ret)
      (org-defkey map [(return)] 'org-goto-ret)

#+end_src

The version of org-mode with the issue:

#+begin_src elisp
  (org-version nil t)
  ;;=> "Org mode version 9.7-pre (release_9.6.19-1208-g7360c6 @ 
/home/git/org-mode/lisp/)"

#+end_src




Re: [FR] Should we resolve environment variables in the file link path when exporting? (was: [FR] Please add environment variable substitution in `org-display-inline-images')

2023-06-01 Thread Pan Xie
Oh, that path will be horrible! Variable substitution is really 
important since it is an abstraction to make the same org file works on 
different hosts with different path hierarchies. I believe there are 
lots of users already rely on it, even without being documented. The 
reasonable thinking would be supporting more substitutions, rather than 
remove any.


On 6/1/23 16:35, Ihor Radchenko wrote:

Pan Xie  writes:


I think we need keep consistent with the file link. Since file link will
substitute the environment variables in its file path, I guess it will
do the same thing when export to html files. It may keep the variables
when export to Org (ox-org). Since both image link and file link are
links, from user's perspective they should be consistent.

This feature is not even documented. We may as well go other way and
remove variable substitution from the file links and keep the rest
unchanged. Not that we have to. But I think that the topic is worth
discussing first.





Re: [FR] Should we resolve environment variables in the file link path when exporting? (was: [FR] Please add environment variable substitution in `org-display-inline-images')

2023-06-01 Thread Pan Xie
I think we need keep consistent with the file link. Since file link will 
substitute the environment variables in its file path, I guess it will 
do the same thing when export to html files. It may keep the variables 
when export to Org (ox-org). Since both image link and file link are 
links, from user's perspective they should be consistent.


On 6/1/23 16:20, Ihor Radchenko wrote:

Pan Xie  writes:


Fantastic!! Thanks for your help. I can remove my ugly override codes.

BTW, Please keep in mind that the org export codes also need to
substitute the environment variables. My proposal only works for the org
file itself, When exports the org file to html, the image file path will
still include the environment variable, which is of course not correct.

It may or may not be correct.
For example, when exporting to Org (ox-org), one may want to keep the
environment variables.

If we add this feature for export, it should be an export option.
It will also be a breaking change.

I generally feel that it should be reasonable to go ahead with this
breaking change, possibly disabling variable resolution for ox-org only.





Re: [FR] Please add environment variable substitution in `org-display-inline-images'

2023-05-31 Thread Pan Xie
I think that depends on whether the linter will verify the existence of 
each file path. Strictly speaking, it should, thus the org-lint also 
need changing. On the other hand, if the tool just verify the grammar of 
the org file itself, then it might be OK without changing. I never use 
the linter before, might give it a try sometime.



But the export functionality definitely need changing, otherwise the 
images won't be shown in exported html (or other format) files, and 
someone will report a bug.


On 6/1/23 08:12, Samuel Wales wrote:

org-lint might need changing too?

On 5/31/23, Pan Xie  wrote:

Fantastic!! Thanks for your help. I can remove my ugly override codes.

BTW, Please keep in mind that the org export codes also need to
substitute the environment variables. My proposal only works for the org
file itself, When exports the org file to html, the image file path will
still include the environment variable, which is of course not correct.

On 5/31/23 16:24, Ihor Radchenko wrote:

Pan Xie  writes:


I recently found that the environment variable substitution does not
apply to inline image paths. Supposing I use a path
“/home/pxie/$Gallery/” to store all my image files, “$Gallery”
should be substituted with its corresponding value. The file link DOES
substitute the environment variables, but inline image paths not. So I
think it is a reasonable demand for the consistency.

Agree.
Done, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3123caa8e









Re: [FR] Please add environment variable substitution in `org-display-inline-images'

2023-05-31 Thread Pan Xie

Fantastic!! Thanks for your help. I can remove my ugly override codes.

BTW, Please keep in mind that the org export codes also need to 
substitute the environment variables. My proposal only works for the org 
file itself, When exports the org file to html, the image file path will 
still include the environment variable, which is of course not correct.


On 5/31/23 16:24, Ihor Radchenko wrote:

Pan Xie  writes:


I recently found that the environment variable substitution does not
apply to inline image paths. Supposing I use a path
“/home/pxie/$Gallery/” to store all my image files, “$Gallery”
should be substituted with its corresponding value. The file link DOES
substitute the environment variables, but inline image paths not. So I
think it is a reasonable demand for the consistency.

Agree.
Done, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3123caa8e





[FR] Please add environment variable substitution in `org-display-inline-images'

2023-05-28 Thread Pan Xie

Hello,

I recently found that the environment variable substitution does not
apply to inline image paths. Supposing I use a path
“/home/pxie/$Gallery/” to store all my image files, “$Gallery”
should be substituted with its corresponding value. The file link DOES
substitute the environment variables, but inline image paths not. So I
think it is a reasonable demand for the consistency.

It is also very important for my and other users' (I strongly believe)
configurations. Environment variable is the key abstraction to make
the same org document works on different machines with different path
hierarchies.

I hunt down the codes and find just one line change can fix that. In
`org-display-inline-images' function, add `substitute-in-file-name' to
the `expand-file-name' call. I can override the function with the
solution but I hope it can be added to the official codes.

So my proposal of the code change would be (find "pxie" in the codes):

#+begin_src elisp
(defun org-display-inline-images ( include-linked refresh beg end)
  "Display inline images.

An inline image is a link which follows either of these
conventions:

  1. Its path is a file with an extension matching return value
 from `image-file-name-regexp' and it has no contents.

  2. Its description consists in a single link of the previous
 type.  In this case, that link must be a well-formed plain
 or angle link, i.e., it must have an explicit \"file\" type.

Equip each image with the key-map `image-map'.

When optional argument INCLUDE-LINKED is non-nil, also links with
a text description part will be inlined.  This can be nice for
a quick look at those images, but it does not reflect what
exported files will look like.

When optional argument REFRESH is non-nil, refresh existing
images between BEG and END.  This will create new image displays
only if necessary.

BEG and END define the considered part.  They default to the
buffer boundaries with possible narrowing."
  (interactive "P")
  (when (display-graphic-p)
    (when refresh
  (org-remove-inline-images beg end)
  (when (fboundp 'clear-image-cache) (clear-image-cache)))
    (let ((end (or end (point-max
  (org-with-point-at (or beg (point-min))
    (let* ((case-fold-search t)
       (file-extension-re (image-file-name-regexp))
       (link-abbrevs (mapcar #'car
             (append org-link-abbrev-alist-local
                 org-link-abbrev-alist)))
       ;; Check absolute, relative file names and explicit
       ;; "file:" links.  Also check link abbreviations since
       ;; some might expand to "file" links.
       (file-types-re
    (format 
"\\[\\[\\(?:file%s:\\|attachment:\\|[./~]\\)\\|\\]\\[\\(
        (if (not link-abbrevs) ""
          (concat "\\|" (regexp-opt link-abbrevs))
      (while (re-search-forward file-types-re end t)
    (let* ((link (org-element-lineage
          (save-match-data (org-element-context))
          '(link) t))
   (linktype (org-element-property :type link))
       (inner-start (match-beginning 1))
       (path
        (cond
     ;; No link at point; no inline image.
     ((not link) nil)
     ;; File link without a description.  Also handle
     ;; INCLUDE-LINKED here since it should have
     ;; precedence over the next case.  I.e., if link
     ;; contains filenames in both the path and the
     ;; description, prioritize the path only when
     ;; INCLUDE-LINKED is non-nil.
     ((or (not (org-element-property :contents-begin link))
          include-linked)
      (and (or (equal "file" linktype)
   (equal "attachment" linktype))
           (org-element-property :path link)))
     ;; Link with a description.  Check if description
     ;; is a filename.  Even if Org doesn't have syntax
     ;; for those -- clickable image -- constructs, fake
     ;; them, as in `org-export-insert-image-links'.
     ((not inner-start) nil)
     (t
      (org-with-point-at inner-start
        (and (looking-at
          (if (char-equal ?< (char-after inner-start))
              org-link-angle-re
            org-link-plain-re))
         ;; File name must fill the whole
         ;; description.
         (= (org-element-property :contents-end link)
            (match-end 0))
         (match-string 2)))
      (when (and path (string-match-p file-extension-re path))
    (let ((file (if (equal "attachment" linktype)
            (progn
  (require 'org-attach)
              (ignore-errors (org-attach-expand path)))
;;; {{{ pxie changes begin
  (expand-file-name 
(substitute-in-file-name path)

;;; }}} pxie changes end
      (when (and file