profile
viewpoint

slayer152/PackageResourceViewer 0

Sublime Text plugin to view package resources.

slayer152/ripgrep 0

ripgrep recursively searches directories for a regex pattern while respecting your gitignore

slayer152/sv-parser 0

SystemVerilog parser library fully complient with IEEE 1800-2017

issue commentoantolin/embark

embark-target-file-at-point not properly recognizing filenames?

So, I'm guessing that in your situation that M-x ffap isn't finding the file either, is it? How do you use that C file? Do you compile it specifying an include path? Instead of adding your own Embark target you might want to configure ffap to find the correct file instead: just add the directories to user option ffap-c-path.

Yes, M-x ffap doesn't find it. Not C files; the files are in an in-house language and are generated by various flows that can put them in one of ten/hundred directories inside a project. Something like files x, y... generate <filename> which is #include'd in file z. The build flow puts the path of <filename> in another file a1 and a1 is passed to the compiler to compile z.

I'm not sure if I want to look at configuring ffap-c-path because there can be hundreds of #include <filename> in each file and the files are distributed over several directories (even the a1-like files containing filepaths are put in several directories).

So, I'm thinking one of these two:

  • With <filename> at point -> consult-find-file -> M-n/future history -> embark-act -> my/function with completion-candidate as the file target. OR,
  • Defining my own target and starting with embark-act

Option 1 is easier but I'm training my muscle memory to instinctively use embark-act as the front/initial command AMAP. I didn't get the hang of Embark initially but @karthink's post with the gifs was the 'Aha!' moment for me (I'm more of a visual learner). Thank you for this package!

slayer152

comment created time in a month

issue commentoantolin/embark

embark-target-file-at-point not properly recognizing filenames?

Sorry, I should have described the case better.

abcd.txt doesn't exist in the current directory. My use-case is actually detecting a file at point in a regular buffer even if the file is in a different directory, e.g. files in pre-processor directives like #include <filename>.

On second thought, I guess this detection wouldn't make much sense as most of the actions on files in the embark-file-map won't work if the full file location is not known when embark-act is called. I think it may be better if I detect this as a new target in my config.

Sorry for the trouble - please close this if you agree or I can close this too.

slayer152

comment created time in a month

issue openedoantolin/embark

embark-target-file-at-point not properly recognizing filenames?

embark-act on, say, abcd.txt, in a regular buffer does not recognize file as a target. It looks like embark-target-file-at-point relies first on ffap-file-at-point (which returns nil in the example) and uses (thing-at-point 'filename) only if ffap-file-at-point is non-nil.

I also don't understand the reference to ffap-el-mode in this function but should embark-target-file-at-point also be looking at (thing-at-point 'filename) if ffap-file-at-point returns nil ?

created time in a month

issue commentminad/consult

Enhancement: customizable list of symbols to try to get the 'thing at point' used in future history

I'm a little surprised at what you said about cycling: I thought that the next target after url would be symbol, and that the symbol target would be exactly abcd@gmail.com.

It depends on the major mode, right? In the modes (Text mode, Verilog mode and modes to support the many in-house languages typical in EDA companies) I usually work in, the target is not abcd@gmail.com. E.g. With point somewhere on abcd@gmail.com in Text mode, I can only cycle through url -> identifier -> sentence -> paragraph -> url ... In Verilog mode, I can cycle through url -> identifier -> defun -> url...

But anyway, I just made the change I mentioned, and now there is a new email target which does not have the mailto: prefix (which a single "compose mail" action). See oantolin/embark@4b5325b

Wow, that was quick - 'email' shows up now as the first target in my example. Thank you, @oantolin .

slayer152

comment created time in a month

issue commentminad/consult

Enhancement: customizable list of symbols to try to get the 'thing at point' used in future history

Oh, you don't have to choose: you can run the Consult command as an Embark action in both cases! Say you bind embark-act to C-., for instance. Then in some buffer if you have no region active, C-. C l would typically search for the symbol at point (or maybe file at point, url at point, s-expression at point, etc.

This doesn't readily work in one of my main use-cases and that's what prompted me to post this request. I often have to work with email ids in text documents - with point on a email id (say, abcd@gmail.com), embark-act recognizes the target as a url '**mailto:**abcd@gmail.com' (cycling through other targets doesn't recognize the email id). I'd like to avoid adding any elbow grease to remove the 'mailto:' part (which may be simple enough), if possible.

slayer152

comment created time in a month

issue commentminad/consult

Enhancement: customizable list of symbols to try to get the 'thing at point' used in future history

If you want to run a Consult command on the active region, you can just run the Consult command as an Embark action after marking the region.

Yes, but it's just that I have to pause mentally to determine what should be done next based on my target - Consult command as an Embark action if selected region or get thing at point from future history. I mostly use Embark only in the minibuffer and it may be just a matter of time before I get to using it in a normal buffer and training my muscle memory.

I may be in a small minority who will benefit from adding the selected region to future history but nevertheless wanted to request support for it. Please feel free to close the issue if Daniel and you think it's too niche of a request to support or please let me know and I will close it.

slayer152

comment created time in a month

fork slayer152/ripgrep

ripgrep recursively searches directories for a regex pattern while respecting your gitignore

fork in a month

issue commentminad/consult

Enhancement: customizable list of symbols to try to get the 'thing at point' used in future history

This is only possible if you set default=nil. The first element of the future history is always the default value. Got it, thanks.

I have to think about this more - I am not yet convinced I will go with this solution. Noted. As an alternative, would you consider adding any selected region to the future history for all consult commands (user can exactly select what they want and just use muscle memory to get it from future history)?

slayer152

comment created time in a month

issue commentminad/consult

Enhancement: customizable list of symbols to try to get the 'thing at point' used in future history

Thanks, Daniel and Omar for the comments and thanks to Daniel for quickly pushing a prototype.

A couple of follow up questions:

  • Is there any specific advantage using (consult-customize ... :initial (:eval ...)) over a wrapper function for getting initial value?
  • I'm experimenting a bit and tried this: (consult-customize my/consult-line-thing-at-point :add-history (:eval (or (thing-at-point 'region) (thing-at-point 'email) (thing-at-point 'url) (thing-at-point 'symbol)))) If point is at, say, an email and I execute my/consult-line-thing-at-point, it looks like 1) the non-blank line at point is still in the future history - how does this happen, and 2) the email-at-point can be selected only after I hit M-n (next-history-element) twice; the non-blank line at point seems to be the first thing selected by default). Is there a way to change this (so that the email is the first thing I get from future history).
slayer152

comment created time in 2 months

issue openedminad/consult

Enhancement: customizable list of symbols to try to get the 'thing at point' used in future history

Can consult functions be enhanced to support a customizable list of symbols to find the 'thing at point' added to future history?

Mainly because the fixed thing-at-point used in each consult function may not always be the right choice to add to future history. For e.g., the symbol at point may not always be the right input for consult-grep; in some cases I want the selected region or email at point.

So, maybe consult-find uses a customizable variable with default as '(region filename symbol) and consult-grep uses '(region email symbol sexp) and so on?

I understand that one can write small wrapper functions around consult's function to achieve this or perhaps use embark, but it would great if supported natively in consult since there's already basic support of the specific thing-at-point in consult functions.

IMO, this would help with consistent user experience wrt getting the desired input from future history. Thank you for your attention.

created time in 2 months

more